The permission architecture of censhare is controlled through permission keys, permission sets, roles, and domains.

Context

Users work in a default role in their default domain, and can have additional roles in other domains. User workspaces can be customized for different roles.

Permission key, permission sets and roles are managed in the censhare Admin Client. When you create users, their roles must be configured in the censhare Admin Client.

Introduction

To work in censhare, every user must be assigned to:

  • A default domain:  It determines where a user usually works in censhare. That is, which sub-area a user can see and carry out their tasks in.

  • A default role:  It determines what a user can do in censhare. That is, which functions and features a user can carry out.

A role must have permission sets assigned to it. Permission sets bundle individual permissions. You can add or remove permission sets to a role as necessary. Single permissions cannot be assigned to a role or to a user. They must be part of a permission set to be assigned to a role. Permissions are defined in  permission keys.

censhare provides more than 100 default  permission keys  for a fine-grained access control to work areas, applications and functions.

The desired permissions are assigned indirectly to a user with a  role. When you add a user to the Master data/Users table in the censhare Admin Client, you must select a default role and default domain for the user.


censhare Permission architecture

Secondary roles and domains

Besides the default domain and role, you can give users access to other domains. In these domains, users can have a different role. The default domain is the domain in which a user usually works in censhare. Assets that a user creates are stored in the default domain. The additional roles/domains ensure that users get all the functionality they need, and that they can share information with others.

The respective roles/domains configuration of a user depends on the governance model and the domain tree design of your system.

For example, the  censhare standard workspace for dedicated solutions  requires that users have access to the  common resources and  share domains. The permissions to these domains can be restricted to the basic permissions.

Permission keys

The censhare standard workspace contains more than 100 permission keys. The permission keys control which applications a user can launch and which features within an application can be used. To access the list of available permission keys, open the Master data/Permission keys table in the censhare Admin Client.

The permission key configuration is locked and can only be edited in Admin mode. In the permission key configuration, you can do the following:

  • Edit the name or localized names of a permission key

  • Edit the description or localized description of a permission key.

Do not change the ID of a permission key or remove a permission key! The permission keys are hard-coded in censhare Web and the censhare Clients. For highly customized solutions, it is possible to implement new permission keys. 

Permission sets

Permission sets bundle individual permission keys. The censhare standard workspace for dedicated solutions contains default permission sets that can be used with the respective roles. If you create your own permission sets, it is best practice to create them as functional, meaningful entities.

Permission sets are stored in the master data and can be accessed in the  Master data/Permission sets  table of the censhare Admin Client. Permission sets are unlocked and can be altered at any time. You can do the following:

  • Create new permission sets and assign individual permission keys.

  • Modify an existing permission set.

  • Remove an existing permission set.

The default  System Administrator  permission set grants full access to all clients. If you do not require this permission set, we recommend to remove it.

All other default permission sets are used in the governance model of the censhare standard workspace for dedicated solutions. Any changes of these affect the correct function of a system that is based on the dedicated solutions framework.

Roles

Roles define a work profile for a user in a given domain. Roles require at least one permission set. You cannot assign individual permission keys to a role. To assign a single permission key, first create a permission set with the respective permission key, and assign this permission set to a role.

A role can combine multiple permission sets. In a role, each permission set can be restricted to a range of workflow states.

The workspace and user interface of censhare Web (for example: dashboards, asset pages, action menus) can be customized for different roles.

Roles can be accessed in the  Master data/Roles  table of the censhare Admin Client. Roles are unlocked and can be altered at any time. You can do the following:

  • Add new roles. Assign permission sets. Set the workflow state range for each permission set.

  • Edit existing roles. Add or remove permission sets. Change the workflow state range for permission sets.

Workflow states and workflow target states

Optionally, for each permission set that you assign to a role, you can define a range of workflow states and workflow target states. This restricts the permissions to assets in the workflow steps that are associated with the respective workflow states:

  • The  workflow state  range defines, in which workflow states of an asset users can perform the tasks and functions associated with the respective permission set. The user with the respective role cannot work with assets in out-of-range workflow states, unless the same role comprises a different permission set for the out-of-range workflow states.

  • The  workflow target state  range defines, which workflow steps users can set when they edit an asset (workflow steps are mapped to a workflow state in the Workflows configuration).

Tip:  As a common practice, the workflow target state range comprises one additional workflow state to the workflow state range. For example, if a role grants permissions from the workflow states  In planning  to  Work in progress, the workflow target range should be from  In planning  to  In approval. This allows users to hand over their assets to approval when they finish their work.

Users

Users work in censhare Web or the censhare Client with their default role in their default domain. If users have additional roles in other domains, they can access these domains and perform the respective tasks.

You must always assign a role/domain pair to grant permissions to a user. You cannot assign individual assign permission keys, permission sets, or roles without a domain to a user.

Depending on your governance model, it can be necessary to assign multiple roles to a user. For example, the censhare standard workspace for dedicated solutions requires permissions to the  common resources  and  share  domains. Therefore, besides default role (for example: Specialist), you must assign additional roles to every user for these domains.

Result

You know how to use and create permission sets and roles. You know how to assign roles to users in their default and additional domains.