Access Group form
Completing the Layout tab

Field

Description

Enter the first key part of an application rule (Rule-Application rule type) to be available to all users associated with this access group. As a user signs on, Process Commander adds the RuleSets and Versions identified in this application rule to the user's RuleSet list.

(Leave blank in legacy configurations only.)

Field

Description

Optional. List all class groups for work pools in which users associated with this access group are permitted to enter new work objects. Each class group defines a work pool, a named collection of work types.

Leave blank if users who enter new work objects and are associated with this access group use a composite portal that includes the standard section rule @baseclass.NewWork. The work types that such users can enter appear on the Details tab of the Application rule, not here. See How to create a composite portal.

Leave blank if users associated with this work object do not enter new work.

For users of the traditional WorkUser or WorkManager portal rules, this list determines the set of work pool names that appear in the Work Pool Selector (typically visible below the logo in the navigation panel) and the work types that appear in the selection list of the New.. box. The names appear in the order that the work pools are listed.

Select one radio button to mark as Default the class group that holds the work types in which users associated with this access group most often enter work objects. For User portals, this determines the work pool name that appears in the work pool selector below the logo.

For example, if you designate the PegaSample class group as default, the corresponding work pool name is Sample Work.

When a user (at a traditional portal) associated with this access group enters new work objects, the available work types are those from classes (work types) in the designated class group (work pool).

The system obtains the work pool name text from the Short Description text of the class rule that has the same name as the class group.

You can enter any class group on this list 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 work types) are available to users associated with this access group.

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.

If you leave this array blank, operators associated with this access group cannot enter new work. However, the Work Pools array does not affect which work objects the operator can update, only which types of work objects the operator can create. Which assignments the operator can open and update is determined by access roles and RuleSet lists, not by the work pools.

Many reports in the Monitor Activity workspace cover business processing for a selected work pool. For an access group to be associated with managers, list all work pools that correspond to applications they may want to report on, whether or not they enter new work in these work pools.

Field

Description

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

For a development Process Commander system, commonly assigned access role names are the three standards:

• For a worker, use PegaRULES:User4
• For a work manager, use PegaRULES:WorkMgr4
• For all developers, use PegaRULES:SysAdm4

Enter an access role that is consistent with the value you entered in the Default Portal Layout field in the Settings tab.

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.

As a best practice to reduce future maintenance, list only roles for one application. For workers or managers who routinely work in multiple applications, create separate access groups for each application, and list all but one in the Additional array on the Operator tab of the Operator ID instance.

To retain support for access groups created in Process Commander Version 4, the additional roles PegaRULES:ProArch4 and PegaRULES:SysArch4 remain available. These two roles are deprecated and not recommended for new development.

Field

Description

Optional. Enter the RuleSets and Versions specific to this access group.

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 General 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:

• 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 customization RuleSet for storing only those rules that are personal customized versions of list view or summary view reports.)

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.