PEGA Process Commander Fundamentals

Pega properties with the pz prefix (Pz, D) are personalized properties explicitly intended for modification by end users. Properties with px (A) are protected system properties that cannot be modified. Properties with py (B) are internal properties used by the Pega platform. The pz designation allows safe customization without affecting system behavior.

Pega's out-of-the-box 'Default' SLA rule automatically applies a goal of two days and a deadline of five days to the assignment. It does not perform automatic routing or escalations by default.

This question asks which statement is FALSE. Statement C is false because a Work Pool is not a storage entity - it is a logical grouping mechanism. Work objects are stored in the database, not in the Work Pool itself. Statements A, B, and D are true: Work baskets ARE instances of Data-Admin-WorkBasket, Work lists relate to operators, and Access roles should be isolated per application.

In Pega's UI hierarchy, Harness rules contain containers, which can contain sections (D). Additionally, sections can contain containers which can in turn contain other sections (E), allowing nested UI structures. Statement A is false because containers contain sections, not the reverse. Statement B is false because Layouts DO have rows and columns. Statement C is false because sections CAN contain other sections.

The standard Pega class for representing an 'Originator' party is Data-Party-Operator (B). This follows Pega's naming convention where the class structure is Data-[Purpose]-[Entity]. The options A (Data-Operator-Party), C (Party-Data-Operator), and D (Party-Operator-Data) do not follow the correct class naming pattern.

Property-Map-Value calls a Rule-Obj-MapValue with a single row input. Property-Map-ValuePair calls the same Rule-Obj-MapValue but passes a single row AND a single column input, allowing lookups that depend on two dimensions. Option A is incorrect about the number of calls. Option B incorrectly mentions 'two row inputs'. Option D incorrectly mentions 'multiple row inputs'.

A business user is the end user who operates the Pega application to receive, process, and resolve tasks. Managers, architects, and administrators are responsible for supervising, designing, and maintaining the system.

Dynamic select (B) is the feature where one field's value selection determines the available values in another field (e.g., Make determines Model). This cascading selection is implemented using Dynamic Class configuration (often referred to as Dynamic select). Property set (A) is for assignment. Dependency list (C) is for controlling rule availability. Obj-List (D) is for database queries.

In Pega, connectors that transition away from an Assignment shape represent flow actions, which define the actions a user can take to complete the task. Other terms like Local action or Branch serve different routing functions.

When an Assignment shape uses Worklist (for operators) but the Router uses ToWorkbasket (for baskets), there is a routing mismatch. This causes the flow to suspend and transfer control to the FlowProblems flow (D), which handles such incompatibility errors. The flow will save initially but execution fails. It does not simply fail to save (A), nor does it continue with a Java exception (C).

In Pega, an Integrator shape is specifically used to connect to external systems via connector rules. It does not represent user interfaces or handle incoming service requests.

In Pega, the TaskStatus-Set method is used in a utility activity to set a specific status that transitions can subsequently evaluate. Java steps and History-Add do not set this flow-testable status.

In Process Commander's organizational hierarchy, the Unit level (C) is the most granular and important for work identification and assignment. While Division (A), Work Group (B), and Organization (D) exist, the Unit provides the finest level of work allocation and is the primary level for routing work to specific teams or individuals within the organizational structure.

The RuleSet list consolidates information from four key sources: Division (which provides organizational-level rules), Access Group (determining user permissions), Requester Type (defining access context), and Organization (providing enterprise-wide rules). Access Roles and Operators are not part of RuleSet assembly.

In the Work Object Model, the correct hierarchy is Folder (highest level container), Cover (groups related work objects), and Basic (individual work items). This hierarchy supports efficient organization and management of related work.

The statement is false. PRPC's class structure and inheritance hierarchy already handle repeating groups effectively through embedded properties and page lists. You do NOT need to design additional classes to represent repeating groups - the platform provides built-in mechanisms for this.

The statement is false. Process Commander uses a proprietary database architecture, not an open one. While it does support Microsoft SQL Server, Oracle, and IBM DB2, the architecture itself is not 'open' - it uses Pega-specific storage mechanisms and schemas.

A work pool is the visible representation of a collection of related work that is routinely numbered, managed, and reported together. It's not about grouping subordinate objects (that's a cover) or interested parties (that's a work party).

A class group causes PRPC to store instances from multiple concrete classes sharing a common key format in a single database table. This is a database optimization technique that reduces table proliferation while maintaining logical separation at the application level.