Privileges and roles

Dimensions CM uses roles and privileges to determine the functions that different users or groups can perform.

In this topic:

Users and groups

Users are registered in Dimensions CM with a username and password.

The operations user can perform, and the object classes they can perform them on, are determined by the privileges and/or role assignments that have been defined for them.

In Administration Console, you can create groups of users, and control access and privileges by assigning them to a group.

For details about assigning roles and privileges in the Administration Console, see Users and roles management.

Back to top

Roles vs privileges

Dimensions CM uses roles and privileges to control the functions that users can perform, and the object classes they can perform them on:

Roles

Consist of a collection of privileges that can be assigned to a user or group. For example, if you are assigned the role of PRODUCT-MANAGER, you can perform all the functions enabled for the role. You can create custom roles or use one of the Dimensions CM predefined roles, and assign that role to one or more users.

Privileges

Determine a particular operation that a user or group can perform on an object class, or an administrative function. For example, editing the content of items or managing lifecycles. For each privilege, you can set privilege rules that define which users or groups can perform certain functions and under what conditions. For example, you can restrict the ability to update a design part to the user who created the design part, or a member of the ADMIN group.

Basic differences between privileges and roles:

• Roles are assigned at product or design part level. You can assign roles to different users for different design parts or child design parts.

  Roles control the ability to action objects through lifecycle transitions, enabling different users to be responsible for different approval stages in the lifecycle.

• Privileges define specific tasks and operations that a user can perform. Privileges can be assigned to specific users and groups or applied to users based on certain privilege rules. Privileges can also be assigned to a role. You cannot restrict them to particular design parts.

  Privileges generally apply to all objects in a particular class.

All implicit privilege definitions that used to be encapsulated in role definitions and inboxes have been made explicit and grantable to users, roles, or groups based on certain rules. This ensures maximum flexibility when enabling certain users to perform specific tasks.

For a description of privileges, see Privilege reference.

For a description of the rules that determine when specific privileges apply, see Privilege rules.

Back to top

Guidelines for granting privileges

Privileges and roles, along with lifecycles and design parts, manage your organization’s process control. When considering the level of process control to implement, follow these guidelines:

• The general grant rules should be sufficient to implement process control for most users.

• Your can grant or deny privileges to specific users. But for administrative and maintenance purposes, it is better to grant the privilege to a group and include the user in that group.

  Note: The more rules you enforce, the more checks are needed, which may impact your system’s performance.

• There may be times when you need to correct or undo an action. For such cases, you could create a group to perform semi-administrative tasks, for example, product-level item privileges Move item to another design part, Action to any state, and Revise item content.

  For example, a user has actioned an item revision to the next normal state but wishes to return the item revision to the previous state.

To achieve tighter process control, use Change Management (CM) rules. For details, see Use Change Management rules.

Back to top

See also:

• Manage the workflow
• Dimensions CM roles