Skip to main content

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 from 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. 

Note: If permissions for a class vary between dependent roles, the access role name inherits the most permissive permission settings. 

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. 

Caution: Configuring an ARO at the application level overrides the corresponding ARO for the dependent role, and any change to the ARO for the dependent role is ignored. 

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.

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice