For Pega Platform versions prior to 8.x, the original recommendation for clients who were implementing applications was to create their own roles by copying or “cloning” the roles that Pega shipped with the application, and then customize them to meet the client’s security model.
When Pega added new functionality to an application and included a new privilege to provide appropriate security for that new feature, the clients’ custom roles would not automatically get this new privilege, but would have to add it manually.
To avoid this manual work, Pega redesigned the role process, and added role dependencies.
The concept behind a role dependency is that instead of a client “cloning” a role and then customizing it, the client creates a new role which is based on – dependent on – a Pega role which is shipped with the product. The client’s new role will not only have the privileges provided by their customized role, but will also inherit the privileges provided by the dependent role.
If Pega releases a new version of the application which requires a new privilege, that new privilege will be added to the appropriate Pega role(s) in the new release.
During the upgrade process, this Pega role will be updated, just as all the other changed rules are. If the client has a role which is dependent upon the updated Pega role, then they will automatically get this new privilege when they upgrade to that new version (rather than having to manually add this new privilege to their custom roles).
Example of Dependent roles
In this example, the application contains the PEBranches:Manager role.
There are no privileges specified in this record, but if you click on the Manage dependent roles button, the Manage Dependent Roles dialog will appear:
This information indicates that the PEBranches:Manager role is dependent upon the shipped PegaRULES:WorkMgr4 role. That means that PEBranches:Manager inherits all the privileges from PegaRULES:WorkMgr4: