Permission inheritance and dependent roles
Like any other rule type in Pega Platform™, permissions that are configured in a parent class are inherited by child classes. For example, permissions configured in the Work- class apply to instances of Work-Claim, Work-Claim-Boat, and Work-Claim-Boat-Service. However, there may be situations in which a small number of permissions vary between user roles. For example, certain users may need to run reports in one case type but not another. Pega Platform allows developers to simplify permission management by inheriting access control settings for parent classes, which allows you to override only the permissions that need customization while keeping all other permission settings in their default configuration.
Default access roles
When creating a new application, Pega Platform creates access roles for administrators, authors, managers, and users. Each application-specific role inherits permissions from a standard access role provided as part of core Pega Platform functionality. The standard access role from which permissions are inherited is called a dependent role.
Dependent roles allow you to customize access control for use cases that require specific permissions while otherwise retaining permissions inherited from a standard access role. The use of dependent roles helps to standardize permissions across applications and improves the maintainability of the access control model.
Standard access roles
By default, Access Role Name records reference at least one standard access role as a dependent role. For example, the <ApplicationName>:Author role created for an application is based on the standard PegaRULES:SysAdm4 role, which lists the default access control settings for application developers.
Some of the standard access roles provided with Pega Platform are listed in the following table.
| Access role name | Purpose |
|---|---|
| PegaRULES:SysAdm4 | Developer with full capabilities |
| PegaRULES:User1 | Application user with limited capabilities and may not perform assignments on worklists other than own worklist |
| PegaRULES:User4 | Users with broader capabilities may open any work object in the application but perform assignments only on their worklists. |
| PegaRULES:WorkMgr4 | Work manager will full capabilities that can view and update delegated rules |
| PegaRULES:Guest | Unauthenticated access with minimum access |
| PegaRULES:Guest-Maximum | Unauthenticated access with more capabilities, including the ability to open and update work items assigned to self |
| PegaRULES:Batch | For background requestors, including agents |
| PegaRULES:AutoTest | Access to Automated Unit Testing |
| PegaRULES:SysArch4 | For a business analyst or system architect who defines processes, classes, and properties and who may develop activities |
| PegaRULES:ProArch4 | For a process architect who focuses on flows and other rules in the Process and User Interface categories |
| PegaRULES:EditorCollaborator | For collaborators that participate in the development of the application as editors. Can view and change application assets |
| PegaRULES:ViewerCollaborator | For collaborators that participate in the development of the application as reviewers. Can view application assets but cannot change them |
| PegaRULES:PegaAPI | Must be explicitly added to a user's access group in order to use the Pega API |
Permissions configured on an Access Role Name record override any permissions configured for all dependent roles. To view the dependent roles applied to an access role, click Manage dependent roles on the Access Role Name record.
Customization of access roles based on dependent roles
To build for reusability and change, start with the default permissions of an access role and only customize permissions where you need them. Pega Platform allows you to customize an access role based on one or more dependent roles.
To customize a small number of classes for an access role, customize the Access Role to Object (ARO) records at the appropriate class level in your application's hierarchy.
When configuring an access role, determine the actions and classes for which you need to customize permissions. Next, decide if you can use the default permissions configured in a Standard Access Role. If so, no further customization is necessary. However, if you need to customize any permissions, customize the ARO record at the appropriate class level.
In the following image, click the + icons to learn more about the customization of access roles.
Check your knowledge with the following interaction.
Want to help us improve this content?