TABLE OF CONTENTS

Explanation of term

d.vinci software products are based on role-based access control to enhance security when handling sensitive data.

  • Rights
    Users can only perform actions for which they have the necessary rights. This includes the ability to view content and perform actions. If a user lacks the required rights, content will not be displayed, and buttons for actions will be hidden.
    Example right: View applications

  • Permissions
    Users receive rights in the form of permissions. A permission is an object in d.vinci that can be selected and assigned.
    Permissions cannot be assigned directly to users. Instead, they are added to roles and user roles. By assigning roles, users inherit the included permissions and the associated rights.
    Example permission: Applications | view / edit / create / delete

  • Viewing and action permissions
    There is a linguistic distinction between viewing and action permissions. A viewing permission allows a user to see content (by making it visible), while an action permission allows a user to perform actions (by displaying the necessary buttons).
    However, this is purely a linguistic distinction, as viewing permissions are essentially action permissions for seeing content.

  • active and passive permissions
    • active
      Action permissions are active permissions. These grant users the right to actively perform actions. The names of active permissions include the reference object and the associated rights:
      • applications | view / edit / create
      • applications | view / edit / create / delete
    • passive
      passive permissionsgrant users the right to be selected for actions performed by other users, for example:
      • selectable as HR department contact for personnel requests
      • selectable as responsible person for job postings
      • selectable as supervisor for personnel requests

Configuration

Rights are contained within permissions. These permissions are added to a role so that users receive viewing or action permissions.

To do this, open the roles page, create a new role using +role, or click on an existing role and then the edit icon to modify the role and make entries under permissions:

Sometimes, it may be necessary to restrict a specific permission to a particular organizational unit or make it available to all users.
How to do this and an example can be found here: receive recommendations globally


System behavior

New features are often linked to existing or new permissions.

  • If a new feature is linked to an existing permission, it will automatically be available to any user whose user role(s) include that permission.
  • If a new feature is linked to a new permission, you must first manually add this permission to a role so that users assigned to that role can use the new feature. We provide information about this in the release notes.


How our customers use it

Our customers have created very different permission structures using roles.

Roles such as HR department and departmental unit are widely used. However, the permissions stored in our standard user roles often do not perfectly fit the specific application in each company due to different workflows and varying levels of authority.
New roles make it easy to authorize individual users or groups of users for specific tasks or views.

Further articles on this topic