Managing user access with access groups

In Pega, user access to an application is determined by the access group to which a user belongs. Each access group references an application version that the user can access and the roles that the user belongs to when logged in. For each role in an application, you allow or deny actions and privileges to determine what actions users assigned to the role can and cannot perform.

When you extend the access control model for an application, you may need to create additional access groups to implement the entire model. When creating a new access group, consider how the access group differs from existing access groups.

• Identify the application and application version for the access group.
• Identify allowed portals for user interaction.
• Identify allowed access roles for group members.
• Identify the cases that users can create.

If the access group you plan to create does not provide a unique combination of these factors, reevaluate the need for the access group.

When you create a new access group, enter the access group name in the format ApplicationName:JobDescription. For example, to create an access group for auditors for a Purchasing application, use the name Purchasing:Auditors.

Access groups specify the application that members can access. When configuring the access group, identify the application and application version that users will use; this identifies the rulesets that are added to the ruleset list for the user, which determines how users process cases.

To associate the access group with an application, enter the application name and version to the Application section of the Definition tab of the access group record. The following example shows an access group configured to allow users access to version 01.01.01 of the HRApps application.

Consider creating a new access group when migrating users to a new application version for user testing or as part of a phased roll-out of an application update. For example, when developing a new minor version of an application, you may want to provide users with early access to the new version without removing their access to the current version. This early access allows users to become familiar with changes to the application and allows users to provide feedback during development.

Since each access group can only reference one application, create an additional access group to allow users to access both application versions. Create a new access group to reference the new application version, and add the access group to the operator ID record. Users can then switch between the two access groups from the Operator menu.

If you need to migrate all members of the access group to a new application version, update the application version on the Definition tab of the access group record rather than create a new access group.

An access group specifies the portal or portals that members of the access group use to perform work. Access groups for end users reference one of the standard end-user portals. When identifying portals to add to an access group, select portals that align to the roles assigned to the access group. For example, if members of an access group are managers, add the Manager portal to the access group record. To add a portal to an access group record, list the portal in the Available portals section of the Definition tab of the access group record.

When adding portals to an access group, identify a default portal to present to users upon login. The following example shows an access group configured to allow users access to the Manager and User portals. In this configuration, Pega presents the Manager portal to members of the access group after they log in.

If an access group lists more than one portal, the remaining portals are available to users from the Operator menu.

An access group identifies the access roles granted to members of the group. As you extend the access control model for your application, you add new roles to an access group. Adding a role to an access group grants the access control and privileges for the role to the user. To add an access role to an access group, list the Access Role Name record in the Available roles section of the Definition tab of the access group record.

When configuring an access group, identify the access roles that grant or deny privileges to match the needs of members of the access group. An access group can reference more than one access role.

For example, an application allows employees to submit expense reports for reimbursement. The application then assigns the case to the manager of the user for review. However, managers also submit expense reports. So managers perform tasks associated with both the user and manager roles. In this situation, you apply both roles to the access group for managers.

When an access group references more than one access role, Pega applies the most-permissive setting across all the access roles.

An access group identifies the types of cases that members of the group can create and process. To identify the case types that members can create, you identify one or more work pools for the access group on the Advanced tab of the access group record.

A work pool is a set of case types a user can work on in an application. Each work pool corresponds to a class group defined in the application or a built-on application. Users in an access group can only create cases from class groups identified as a work pool for the access group. For example, Tom is a member of the Users access group, while Mary is a member of the Managers access group. The Managers access group lists a class group that contains the Transaction override case type, but the Users access group does not. Mary can create a Transaction override case. Tom cannot create a Transaction override case.