You are here: Reference > Data classes > Access Group data instances > Access Group form - Completing the Layout tab

Access Group form – Completing the Definition tab

Complete this tab to identify the application this access group is associated with, and the portals and access roles available to users who reference this access group.

Application

Field

Description

Name

Enter the first key part of an application rule (Rule-Application rule type) to be available to all users associated with this access group. When a user logs in, the RuleSets and Versions identified in this application rule are added to the user's RuleSet list.

(Leave blank in legacy configurations only.)

You can refer to an application rule that lists rulesets and versions, or list them directly in the Production RuleSets array on the Definition tab.

As a best practice, leave the Production RuleSets array blank and refer to an application rule. This approach helps minimizes the number of distinct ruleset lists that users in your system employ. Using fewer distinct ruleset lists can improve system performance and help avoid unplanned differences in ruleset lists among users.

Version

Identify the second key part of an application rule.

Portals

Field

Description

Name

Identify a portal rule to indicate which portal presentation supports those requestors who reference this access group. Click the Open rule icon to open the portal rule.

Select a portal layout that works with the Roles array. Typical choices referencing standard portal rules are:

For a worker, select the Case Worker portal pyCaseWorker.
For a manager, select the Case Manager portal pyCaseManager.
For all developers and system administrators, select the Designer Studio portal Developer.

Use the radio button to select the portal that displays the current application when you open it.

You can use the launch portal menu on the Designer Studio header to open the current application in another portal on this list. Updates to the list are real-time on save.

The Developer portal is designed to support application developers who have the PegaRULES:SysAdm4 access role. Do not enter Developer unless PegaRULES:SysAdm4 appears in the Roles array and Allow rule check out is selected on the Security tab on the Operator ID form.

Roles

Field

Description

Stop privilege checking once a relevant Access of Role to Object instance explicitly denies or grants access

Select this check box to stop searching for relevant Access of Role to Object (Rule-Access-Role-Obj) rules to determine access rights to a class as soon as an access role is found with a relevant Access of Role to Object rule that either grants or denies access.

Leave this check box cleared to use all roles.

Roles

Identify one or more access roles (Rule-Access-Role-Name rule type) that members of this access group acquire at login, in addition to access roles they may acquire from other sources.

For a development system, commonly assigned access role names use these standards:

For a worker, use PegaRULES:User4
For a work manager, use PegaRULES:WorkMgr4
For a business analyst, use PegaRULES:SysArch4
For developers and designers, use PegaRULES:SysAdm4

Enter an access role that is consistent with the default value that you entered in the Portals field.

To improve the application user experience, you can enable client-side rendering of application UI by adding the PegaRULES:TemplateUIEnabled role.

Order is not significant; the access roles available to a user act as a collection of capabilities granted, not a hierarchy.

For non-developer workers and work managers using an application, a best practice is to create and use custom access roles that define the capabilities of the role through Access or Role to Object rules.

The PegaRULES:ProArch4 role is supported but deprecated. Do not use for new development.

About Access Group data instances

Open topic with navigation