Users - Rights and Roles

With rights and roles, you determine who has access to which parts of the platform and what actions users are allowed to perform, such as reading, editing, or publishing. By using roles and rights groups smartly, you keep an overview and ensure a safe and efficient working environment. In this article, we explain how to use rights and roles, the types of roles available, and how to apply them to Portals, CMS, and Knowledge.

In this article:

1. Navigate to rights and roles
2. Working with rights and roles
3. Roles
4. Roles for different components
   • Rights for Portals
   • Rights for Content
   • Rights for Knowledge
   • Rights for widgets in appstore
   • Rights to all components
   • Rights for Social management
   • Rights for Themes
   • Rights for User management
   • User Types
5. Inheritance of rights in Knowledge and Portals
6. Customising rights and roles

Navigate to rights and roles

You can find rights and roles under Embrace > Management > Users.

In the left column, you can navigate to:

• All users
  Overview of all users in the identity provider (IDP) and their roles.
• Roles
  Overview of all roles on this platform.
• Groups
  Overview of all rights groups and the roles they include.

Working with rights and roles

The easiest way to work with rights and roles:

1. Create a rights group
2. Add the roles to the rights group
3. Add the users to the rights group

This way, you keep an overview of which rights users have. You can also easily add a role to a group of administrators. These are two examples of rights groups with their respective roles:

1. Rights group intranet administrators
   • Knowledge manager
   • Portal manager
   • Content manager
   • Media manager
   • Appstore manager
   • Suite application manager
   • Social manager
   • User manager

1. Rights group editors news and content articles
   • Knowledge publisher
   • Content publisher

Roles

Order of the roles. The higher roles also include the rights of the roles below them:

1. Admin - always allowed to do everything (only for Embrace)
2. Manager - allowed to manage rights
3. Publisher - allowed to create, publish and delete
4. Editor - allowed to create and save (not publish)
5. Reader - allowed to read

Roles for different components

Rights for Portals

Managing General dashboard, Group dashboards, pinning widgets.

Rights for Content

Managing news.

Rights for Knowledge

Managing static content: topics, articles and conversations (FAQ and forms).

Rights for widgets in appstore

Managing widgets in the appstore.

Rights to all components

An overarching role for intranet administrators.

Rights for Social management

Managing users, groups, statistics, imports/exports.

Rights for Themes

Managing the styling theme of the intranet: colour usage, font, etc.

Rights for User management

Managing rights and roles for users on the intranet.

User Types

Types of intranet users and their rights.

Inheritance of rights in Knowledge and Portals

In Knowledge and Portals, we work with inheritance of rights. You do not have to assign rights to each article, widget, or news item separately. This happens automatically unless you set it differently. Here's how it works:

1. Top level: Root topic or segment
   • You set the rights here: who may edit, delete, publish, manage or view.
   • News that is not assigned to segments also falls under this top level.
2. Underlying content: Subtopics, articles, Conversations, news items
   • These automatically inherit the rights from their parent topic or segment. This is called inheritance.
     If you move an article to another (sub)topic or a news item to another segment, the rights change accordingly.
   • All content within Embrace normally inherits the rights from the parent item at the top level.
3. Exception: Manually adjusted items
   • If you manually adjust the rights for an article or subtopic, inheritance stops. The content then retains its own settings, even if you later change the parent topic.
   • Content under this manually adjusted item will inherit rights from it unless you also manually adjust the rights there.

Good to know:

• Portals follow the same logic. A widget on a portal inherits rights from the area where it is located. The area normally inherits from the screen and the screen from the Portal itself.
• Content and Knowledge items at the top level inherit rights from the default settings. These settings are described under roles and roles for different components and can only be adjusted by Embrace. It is possible to configure roles manually at the top level to prevent inheritance.

Table: Structure for inheritance. Within a column - with default settings - level 5 inherits rights from level 4; 4 inherits from 3; 3 from 2; and 2 from 1

These levels are not fixed; for example, segments are not necessarily needed in news articles and Conversations. It is good to know that News/Conversations normally inherit from the Segment they belong to, and the Segment inherits from the content type settings for Segments. When no segments are used, News articles and Conversations inherit directly from the content type settings for those content types.

In Knowledge, Media and Portals, you can add extra layers by using more subtopics, subfolders, or subscreens.

Customising rights and roles

With the standard setup of Knowledge and the CMS, a Knowledge editor can manage all items in Knowledge. A Content editor can manage all other content. There is a difference in the actions someone may perform (such as publishing, deleting or editing). But with the standard setting: whoever is allowed to edit may edit everything in that part. This works well for many organisations. Often, the management of the knowledge base and the news lies with one department. Is the management within your organisation divided over several departments? Then it is sometimes necessary to set more specific rights. For example: an HR employee may only edit and publish articles and subtopics under the HR topic.

With a custom user role, you give a user access to a specific part of the Knowledge module. This way, someone can only edit, publish or manage what is necessary. This also works for other components, such as news and applications or portal management in the Portal Builder. For this, you then use a Content Reader role or a Portal Reader role.

Customising rights and roles for Knowledge

1. Go to Management > Users > Roles.

   

2. Create a user role and choose a name and description for the role you want to create. Click Create role when done.

   

3. Find the specific part you want to give access to. If this is in Knowledge:
   • Go to Knowledge > Topics > Main topic structure.
   • Find the topic.
   • Click the three dots (⫶) behind the topic. These appear once you click on the topic.
   • Choose set permissions.

   • Select the role you created in Step 2.

     

4. Then create a rights group via Management > Users > Groups. Add the following roles to this group:
   1. Knowledge Reader for access to the Knowledge module
      1. Portal Reader for access to Portal Builder
      2. Content Reader for News and Applications

   2. The user role you created, such as HR Publisher

      Note: the rights group therefore contains two roles: the Reader role for the module and the custom user role.

5. Add the desired users to the group.

   

Note:

• Do the Knowledge Publishers still need to edit the content? Then set two roles for the permissions in step 3: Knowledge Publisher and HR Publisher.
• A user with custom access sees all published content for which the user has reading rights. Drafts or content without the correct reading rights, so not.