Pega CPBA cheat sheet

Pega Express phases in order: Prepare, Design, Build, Test, Deploy - Prepare establishes the project team and environment before any design work begins.

The Design phase centers on the Delivery Roadmap and the App Studio case lifecycle: every microjourney is mapped to a case type before build starts.

Microjourney = one primary case type plus its supporting case types; a case type should map to one recognizable business outcome, not a department.

A Minimum Lovable Product (MLP) is scoped in the first design sprint; later stages add stages to the same case type rather than creating parallel case types.

Design Thinking stages used in Pega Express: Empathize, Ideate, Prototype, Test - each mapped to a Pega Express workshop activity.

DCO (Direct Capture of Objectives) artifacts live in the application: personas, journeys, and requirements are stored as rules, not external documents.

Guardrail counts (for example warning thresholds on properties per case type or on inheritance depth) are monitored from the Application Guardrails landing page.

Build is incremental by stage and process; each increment is demoed in a Test phase review before the next increment starts.

Case lifecycle = case type → stages → processes → steps; stages may be alternate (parallel) or optional, but only one primary stage is active at a time.

A stage transition resolves in this order: manual transition, then automatic transition conditions, then the stage's default (fall-through) path.

A process is a sequence of shapes; a step is a shape that a user or system performs - assignment shapes create work items, utility shapes do not.

Subcase (child case) creation requires a case type reference on the Create Case step; parent-child data flows only through explicit data propagation, not automatically.

Case status has three parts: stage, status (open, resolved, pending, withdrawn), and resolution - a resolved case can still be reopened if the case type allows it.

A SLA (service level agreement) can be attached to a case, a stage, or an assignment; goal, deadline, and late behavior are defined per interval.

Locking: optimistic locking throws an exception on conflicting save; pessimistic locking holds a lock for the duration of the assignment and blocks other users.

Correspondence is defined once per case type and reused; correspondence fragments allow shared headers and footers across multiple correspondence rules.

Data page scope options: Thread, Requestor, Node, Application - choose the narrowest scope that preserves correctness; Node scope is shared across requestors on one JVM.

Data page refresh strategies: reload if older than, reload once per interaction, reload on the next access, do not reload - refresh is evaluated on each access.

A data type (data object) is backed by a class; the Data Designer creates the class, properties, and the backing data page in one step.

Integration mapping: REST connector for outbound JSON/XML over HTTP; Service REST for inbound; SOAP for legacy WSDL contracts; connector and service are separate rules.

A Data Transform maps source to target; use it for property-level shaping, and use an Activity only when looping, branching, or commit logic is required.

Clipboard structure: pyWorkPage holds the primary case, pyWorkPage.pxThreadPages and pxRequestorPages hold scoped data pages - inspect scope before debugging.

Simulation (data page simulation) lets you test a case type without a live system of record; simulated data is stored as a test data rule.

Report definitions on class join rules: class joins use the class hierarchy, and an explicit join is required when the related class is not a parent or child.

Access control is evaluated as role → access of role to object (ARO) → access when rule (conditional) - the most specific matching rule wins.

Access roles attach to an application's Access Group; a requestor's access group determines which roles apply at runtime.

Attribute-based access control (ABAC) evaluates conditions such as property values at runtime and can grant or deny per case instance.

Privileges are named security checks invoked from activities and flows; they are not the same as roles and do not imply any ARO permissions.

Password policies are set at the application level: length, complexity, history, and lockout thresholds are configurable per policy.

Sensitive properties can be marked for encryption at rest and masked in the UI; masking is display-only and does not change the stored value.

Authentication options include SAML 2.0, OpenID Connect, and LDAP; authorization (what a user may do) is separate from authentication (who they are).

Division of responsibility: the operator record holds identity, the access group holds role assignment, and the application holds the ruleset stack.

A harness defines the overall layout and is chosen by rule resolution; a section is a reusable fragment embedded in a harness or another section.

Layout types: dynamic layout (responsive grid), column layout, and repeating dynamic layout (for lists); choose repeating layout for page-list data.

Responsive breakpoints are configured per application skin; the same section renders differently at each breakpoint without duplicating rules.

A flow action is the UI for one assignment step; it references a section and controls which fields are editable, required, or visible.

Field-level conditions (visibility, disable, required) are expressed as when rules or expressions on the field, not as separate sections.

Cosmos is the default design system theme; it supplies the component library, and custom components are added via the theme, not by editing harnesses.

Localization: field labels use Field Value rules, and the application locale determines which Field Value record is resolved at runtime.

Accessibility: every input needs a label, and the section's accessibility settings control landmark roles and heading levels for screen readers.

Ruleset stack order determines rule resolution: the application's rulesets are searched top-down, and the first matching rule by circumstance and date wins.

Situational Layer Cake: Organization → Division → Unit → Application layers; a rule in a higher layer overrides the same rule in a lower layer.

Rule resolution order: class hierarchy (most specific first), then ruleset list order, then circumstance (property, date, template), then rule availability.

A ruleset version has major, minor, and patch numbers; patch versions are for fixes and must not change behavior visible to users.

A circumstance qualifies a rule so it applies only when a condition holds - circumstance by property, by date, or by template (a combination).

A branch (ruleset branch) isolates development work; merging a branch into the base ruleset requires resolving conflicts rule by rule.

Delegation lets business users edit selected rules (for example decision tables) without opening App Studio; the rule must be marked delegated.

Skimming a class moves its rules to a parent class; specialize-by-copying duplicates rules - skim when behavior is shared, copy when it diverges.

Report types: list, summary, and interactive - summary reports group and aggregate; list reports return detail rows; interactive reports allow runtime filtering.

A report definition's class determines the available properties; joins to related classes must be declared explicitly in the report definition.

Aggregation functions available in summary reports include Count, Sum, Average, Min, Max, and Distinct Count - grouping is by the selected group-by columns.

Report security: reports can be secured with access control so only users with the matching role see the report and its data.

Scheduled reports run as an agent on a schedule and can be delivered by email or saved to a repository; the schedule is stored on the report.

A chart is defined as a separate rule and referenced from a section; the chart's data source is a report definition, not inline SQL.

Subreports and report joins differ: a subreport runs a separate query per row and is slower; a join is a single query and is preferred for large datasets.

Export formats (Excel, CSV, PDF) are configured on the report; column-level formatting comes from the property's display settings, not the report.

Pega Mobile Client wraps the web application in a native container; the app is still rendered from the same rules, so no separate mobile ruleset is required.

Offline support requires the case type to declare which data is cached; offline-enabled cases sync on reconnect and conflicts are resolved by the configured policy.

Mobile app configuration is per application: branding, push notification settings, and the mobile build are managed from the Mobile Channel settings.

Push notifications require a configured provider (for example APNs or FCM) and an operator-level device registration record.

Mobile-friendly UI relies on responsive layouts and the Cosmos theme; avoid fixed-width containers that break at small breakpoints.

Location and camera access are exposed through mobile-specific components; the component degrades gracefully when the capability is unavailable.

Mobile builds are versioned separately from the application ruleset version; a new build is required when native configuration changes, not for rule-only changes.