Access Group form – Completing the Advanced tab

Work pools

Field Description

Field	Description
Name	Lists the classes that are marked as `Is a Class Group` (on the rule form's General tab) for each work pool in which users associated with this access group are permitted to create cases. Each such class defines a work pool, a named collection of case types. You can enter any class group for which the container class (the Rule-Obj-Class instance with the same name as the class group) belongs to a ruleset listed in the Production RuleSets array or available to users through application rules. This restriction ensures that the rules of the application (in addition to the case types) are available to users associated with this access group. As a best practice, select the radio button on the class group that contains the case types in which users associated with this access group most often create cases. This selection determines the default work pool that appears on the top of the Application Explorer tree when you open an application. The names (the class rule Short Description text) of the workpools listed here appear in the Application menu `Switch Work pool` list. If you leave this array blank: When you open an application, the Application Explorer class autocomplete field is empty; no classes appear in the tree. Operators associated with this access group cannot create cases. However, the array does not affect which cases the operator can update, only which types of cases the operator can create. The assignments the operator can open and update is determined by access roles and ruleset lists, not by the work pools. Work pool names appear on this Work Pool Selector list in the order that the corresponding work pools are listed here. If this array contains more than a few, consider reordering them to present the work pool names alphabetically, or in another order meaningful to users. Leave blank if users who enter new cases and are associated with this access group use a composite portal that includes the standard section @baseclass.NewWork. The cases that such users can enter appear on the Cases and Data tab of the Application rule, not here.

Name

Lists the classes that are marked as Is a Class Group (on the rule form's General tab) for each work pool in which users associated with this access group are permitted to create cases. Each such class defines a work pool, a named collection of case types.

You can enter any class group for which the container class (the Rule-Obj-Class instance with the same name as the class group) belongs to a ruleset listed in the Production RuleSets array or available to users through application rules. This restriction ensures that the rules of the application (in addition to the case types) are available to users associated with this access group.

As a best practice, select the radio button on the class group that contains the case types in which users associated with this access group most often create cases. This selection determines the default work pool that appears on the top of the Application Explorer tree when you open an application.

The names (the class rule Short Description text) of the workpools listed here appear in the Application menu Switch Work pool list.

If you leave this array blank:

When you open an application, the Application Explorer class autocomplete field is empty; no classes appear in the tree.
Operators associated with this access group cannot create cases. However, the array does not affect which cases the operator can update, only which types of cases the operator can create. The assignments the operator can open and update is determined by access roles and ruleset lists, not by the work pools.

Work pool names appear on this Work Pool Selector list in the order that the corresponding work pools are listed here. If this array contains more than a few, consider reordering them to present the work pool names alphabetically, or in another order meaningful to users.

Leave blank if users who enter new cases and are associated with this access group use a composite portal that includes the standard section @baseclass.NewWork. The cases that such users can enter appear on the Cases and Data tab of the Application rule, not here.

Access control

Field Description

Field	Description
Authentication timeout	Enter a number of seconds after which the system challenges idle browser sessions (for users of this access group), asking users to re-enter their Operator ID and password. This time-out event does not cause session context or clipboard contents to be lost. If users respond to the challenge and are re-authenticated, they can usually continue processing where they left off, unless the system released locks they held in the meantime, or the system was stopped and restarted. This setting is also taken into account in an offline-enabled application that is either online or offline. When the time-out value is reached, users are automatically logged out when they perform any action and the login screen is redisplayed. Note: This authentication time-out is not related to the `timeout/browser` value in the prconfig.xml file or Dynamic System Settings, which control when passivation occurs.
HTTP/HTTPS home directory	Typically, accept the default of `/webwb`. Directories within this directory hold important static XML forms, JavaScript, style sheets, and images. If you changed the name of this directory, enter the new directory name here.
Rule security mode	This setting determines whether and how the system executes rules accessed by members of this access group. In Pega Platform, rules can be made to require privileges in two ways: By an administrator explicitly editing the rule's Security tab (where such a tab is available). By a Pega Platform activity, pyRuleExecutionMessagesLogged, that automatically generates privileges and adds them to roles that access rules that require privileges. Allow is the default and recommended setting. Deny is the strictest setting and requires creating privileges for rules and access roles. Use Warn mode only when you want to identify rules for which users need generated privileges to execute. You can then use the Pega Platform activity to generate missing privileges and add them to roles where needed. See the PDN article Setting role privileges automatically for access group Deny mode. Select one of these options: Allow [default] - The system allows users in this access group to execute a rule that has no privilege defined, or to execute a privileged rule for which the user has the appropriate privilege. (This includes privileges predefined for standard roles, set by an administrator, or generated by Pega Platform.) This is the default and recommended setting. Deny - The system checks for either of these conditions: A privilege has been specified for the rule: The system checks whether the user has either an explicit privilege, or a generated privilege for the rule. If the user has either privilege, the system executes the rule. If the user has neither privilege, the system denies execution of the rule and logs an error message in the PegaRULES log. No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system denies execution and writes an error message to the PegaRULES log. Warn - The system performs the same checking as in Deny mode, but performs logging only when no privilege has been specified for the rule or the user role: If a privilege has been specified for the rule, the system checks whether the user has either an explicit privilege or a generated privilege for the rule. If the user has neither privilege, the system denies execution of the rule. No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system allows execution and writes a warning message to the PegaRULES log. Warning messages are used to generate privileges with pyRuleExecutionMessagesLogged. A best practice is to use Allow mode for Rule Security Mode, and use the Access Manager to configure authorization for rules. When more specific security is needed for an individual rule, specify a privilege for the rule. See Access of Role to Object form - Completing the Privileges tab. If you want to specify privileges for all rules and users, and you have sufficient time and resources to perform a system-wide exercise including all expected users, see the PDN article Setting role privileges automatically for access group Deny mode.

Authentication timeout

Enter a number of seconds after which the system challenges idle browser sessions (for users of this access group), asking users to re-enter their Operator ID and password. This time-out event does not cause session context or clipboard contents to be lost.

If users respond to the challenge and are re-authenticated, they can usually continue processing where they left off, unless the system released locks they held in the meantime, or the system was stopped and restarted.

This setting is also taken into account in an offline-enabled application that is either online or offline. When the time-out value is reached, users are automatically logged out when they perform any action and the login screen is redisplayed.

Note: This authentication time-out is not related to the timeout/browser value in the prconfig.xml file or Dynamic System Settings, which control when passivation occurs.

HTTP/HTTPS home directory

Typically, accept the default of /webwb. Directories within this directory hold important static XML forms, JavaScript, style sheets, and images.

If you changed the name of this directory, enter the new directory name here.

Rule security mode

This setting determines whether and how the system executes rules accessed by members of this access group.

In Pega Platform, rules can be made to require privileges in two ways:

By an administrator explicitly editing the rule's Security tab (where such a tab is available).
By a Pega Platform activity, pyRuleExecutionMessagesLogged, that automatically generates privileges and adds them to roles that access rules that require privileges.

Allow is the default and recommended setting. Deny is the strictest setting and requires creating privileges for rules and access roles.

Use Warn mode only when you want to identify rules for which users need generated privileges to execute. You can then use the Pega Platform activity to generate missing privileges and add them to roles where needed. See the PDN article Setting role privileges automatically for access group Deny mode.

Select one of these options:

Allow [default] - The system allows users in this access group to execute a rule that has no privilege defined, or to execute a privileged rule for which the user has the appropriate privilege. (This includes privileges predefined for standard roles, set by an administrator, or generated by Pega Platform.) This is the default and recommended setting.
Deny - The system checks for either of these conditions:
- A privilege has been specified for the rule: The system checks whether the user has either an explicit privilege, or a generated privilege for the rule. If the user has either privilege, the system executes the rule. If the user has neither privilege, the system denies execution of the rule and logs an error message in the PegaRULES log.
- No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system denies execution and writes an error message to the PegaRULES log.
Warn - The system performs the same checking as in Deny mode, but performs logging only when no privilege has been specified for the rule or the user role:
- If a privilege has been specified for the rule, the system checks whether the user has either an explicit privilege or a generated privilege for the rule. If the user has neither privilege, the system denies execution of the rule.
- No privilege has been specified for the rule: The system checks whether the user has the generated privilege. If the user lacks the generated privilege, the system allows execution and writes a warning message to the PegaRULES log. Warning messages are used to generate privileges with pyRuleExecutionMessagesLogged.

A best practice is to use Allow mode for Rule Security Mode, and use the Access Manager to configure authorization for rules. When more specific security is needed for an individual rule, specify a privilege for the rule. See Access of Role to Object form - Completing the Privileges tab. If you want to specify privileges for all rules and users, and you have sufficient time and resources to perform a system-wide exercise including all expected users, see the PDN article Setting role privileges automatically for access group Deny mode.

Runtime configuration

Field	Description
Enable accessibility add-on	Select to provide users associated with this access group with more accessible versions of several standard harness, section, and flow actions rather than the normal standard versions. To provide maximum accessibility support, also include the PegaWAI ruleset in the Production RuleSets list for such users. See Understanding accessibility.
Production RuleSets	Optional. Enter production rulesets and versions specific to this access group. For example, in a production setting, you can identify one ruleset and version that remains unlocked and holds only rules expected to be changed often. Such rules can be delegated to management. A ruleset with this purpose is sometimes called a local-only or production ruleset. CAUTION: Leave blank except for developers and others who modify rules. While your profile includes the ruleset versions listed here, they are not considered part of the current application. Rules in the ruleset versions listed here might not be visible in the Application Explorer, Guardrails tool, or Document wizard facilities. As a best practice for good security — and to avoid a warning when you save the Access Group form, select from the ruleset versions that appear in the Production RuleSets array on the Definition tab of the application rule. The system uses this information at log-on time to assemble the ruleset list for this user. The order of your entries in this array affects rule resolution. At login, the system appends these entries to the top of your ruleset list, but starting at the bottom of this array. The order of rows in this array becomes the order they appear in the ruleset list. For example, if during sign-on this access group is accessed when the (partial) ruleset list contains Alpha:01, Beta:02, and Gamma:03 (in that order), and this array contains Red:07, Blue:08, and Green:09 (in that order), the result is Red:07, Blue:08, Green:09, Alpha:01, Beta:02, Gamma:03. You can include a full version number or an initial portion of a version number. Separate the ruleset name from the version (or partial version) with a colon, as in these examples: MORTGAGE:02-07 — Initial portion (major and minor version) MORTGAGE:02-07-20 — Full version number Except for users who have the PegaRULES:WorkUser4 role, include at least one ruleset version that is not locked. If all ruleset versions that a user can access are locked, that user cannot create new rules. (Typically, managers have access to a local customized ruleset for storing only those rules that are personal, customized versions of reports.) Note: List distinct rulesets here. A user or other requestor can access rules in only one major version of a ruleset; access to version 04-10-15 includes access to 04-10-14 and 04-04-11, but not to 03-01-01 or 02-15-07. To reorder the rows of this array, hold the mouse pointer over a number. Click and drag to another row. To duplicate or move a row, hold the mouse pointer over a number. Or, right-click to access a menu with Cut, Copy, and Insert options.

Field

Description

Enable accessibility add-on

Select to provide users associated with this access group with more accessible versions of several standard harness, section, and flow actions rather than the normal standard versions. To provide maximum accessibility support, also include the PegaWAI ruleset in the Production RuleSets list for such users. See Understanding accessibility.

Production RuleSets

Optional. Enter production rulesets and versions specific to this access group. For example, in a production setting, you can identify one ruleset and version that remains unlocked and holds only rules expected to be changed often. Such rules can be delegated to management. A ruleset with this purpose is sometimes called a local-only or production ruleset.

CAUTION:

Leave blank except for developers and others who modify rules. While your profile includes the ruleset versions listed here, they are not considered part of the current application. Rules in the ruleset versions listed here might not be visible in the Application Explorer, Guardrails tool, or Document wizard facilities.

As a best practice for good security — and to avoid a warning when you save the Access Group form, select from the ruleset versions that appear in the Production RuleSets array on the Definition tab of the application rule.

The system uses this information at log-on time to assemble the ruleset list for this user. The order of your entries in this array affects rule resolution. At login, the system appends these entries to the top of your ruleset list, but starting at the bottom of this array. The order of rows in this array becomes the order they appear in the ruleset list.

For example, if during sign-on this access group is accessed when the (partial) ruleset list contains Alpha:01, Beta:02, and Gamma:03 (in that order), and this array contains Red:07, Blue:08, and Green:09 (in that order), the result is Red:07, Blue:08, Green:09, Alpha:01, Beta:02, Gamma:03.

You can include a full version number or an initial portion of a version number. Separate the ruleset name from the version (or partial version) with a colon, as in these examples:

MORTGAGE:02-07 — Initial portion (major and minor version)
MORTGAGE:02-07-20 — Full version number

Except for users who have the PegaRULES:WorkUser4 role, include at least one ruleset version that is not locked. If all ruleset versions that a user can access are locked, that user cannot create new rules. (Typically, managers have access to a local customized ruleset for storing only those rules that are personal, customized versions of reports.)

Note: List distinct rulesets here. A user or other requestor can access rules in only one major version of a ruleset; access to version 04-10-15 includes access to 04-10-14 and 04-04-11, but not to 03-01-01 or 02-15-07.

To reorder the rows of this array, hold the mouse pointer over a number. Click and drag to another row. To duplicate or move a row, hold the mouse pointer over a number. Or, right-click to access a menu with Cut, Copy, and Insert options.

Offline configuration

Field	Description
Enable offline support	Enables offline support for all users of the access group in applications running with Pega Mobile Client. See Offline capability, the How to configure offline capability for mobile app, and the Offline mobility guidelines PDN articles to learn more.
Force full sync for all users	Click to force full data synchronization for all users of the offline-enabled application the next time that they synchronize with the server. If synchronization has already been done at least once, the date/time stamp of when last full data sync operation has occurred is displayed below this button.
Access group requires a connection for portions of the application	Select to allow the offline-enabled application to process online cases and use the OSCO breakout capability. To improve the performance of the offline-enabled application by reducing server load, clear this check box, and also select the Use service session cookie (REST/HTTP only) check box for the offlinehttp service package rule.
Enable caching	Select to enable caching of common rules for all operators in the access group. This option ensures a faster start of offline-enabled applications from the time of the last Pega Platform server start. If you click Force full sync for all users, the cache is automatically cleared. If this check box is selected, you can optionally, in addition to common rules: Cache only the node scope data pages specified in the Node scope data pages list. Cache all node scope data pages except for those specified in the Node scope data pages list. Note: If a rule for an access group is based on an operator record or other data that varies between users within that access group, caching for such an access group should be disabled.
Node scope data pages	Optional. Select one of the following: Specify a list of names of node scope data pages to cache in addition to common rules. Specify the list of names of node scope data pages that should not be cached if Additionally cache all node scope data pages except for those listed below is selected.

Design time configuration

Leave these fields blank for an access group that supports logging on to Pega Platform from external systems, or that supports workers or managers who never create rules.

Field	Description
Default destination ruleset	Optional. Select a ruleset from those listed in the Production RuleSets array or from those listed in the application that the system suggests as a destination ruleset when users associated with this access groups create a rule. If this access group is to support application developers — users who can create rules — select a ruleset that the developers usually work in and add rules to. For managers who are to create and customize reports, select a ruleset that is not intended to be moved to other Pega Platform systems. For language specialists involved in internationalization, select a language-specific ruleset. When a user associated with this access group creates a rule by clicking the New or Save As buttons, the system suggests this ruleset for the new rule. If you leave this field blank, the Save As form uses the ruleset of the existing rule being saved as the default ruleset for the new rule, if a version that is unlocked is available to you.
Version	Optional. Required if the ruleset is not blank. Enter the ruleset version (for the ruleset identified in the previous field) that the requestor associated with this access group usually adds rules into. During New operations (and certain Save As operations), this version appears as the default ruleset version.

Field

Description

Default destination ruleset

Optional. Select a ruleset from those listed in the Production RuleSets array or from those listed in the application that the system suggests as a destination ruleset when users associated with this access groups create a rule.

If this access group is to support application developers — users who can create rules — select a ruleset that the developers usually work in and add rules to.
For managers who are to create and customize reports, select a ruleset that is not intended to be moved to other Pega Platform systems.
For language specialists involved in internationalization, select a language-specific ruleset.

When a user associated with this access group creates a rule by clicking the New or Save As buttons, the system suggests this ruleset for the new rule.

If you leave this field blank, the Save As form uses the ruleset of the existing rule being saved as the default ruleset for the new rule, if a version that is unlocked is available to you.

Version

Optional. Required if the ruleset is not blank. Enter the ruleset version (for the ruleset identified in the previous field) that the requestor associated with this access group usually adds rules into. During New operations (and certain Save As operations), this version appears as the default ruleset version.

About Access Group data instances