Pega LSA cheat sheet

Pega's layered architecture separates the presentation layer (Section, Harness, Flow Action rules), the process layer (Flow, Flow Action, Data Transform), and the data layer (Data Page, Report Definition, Class); changes belong in the layer that owns the concern.

Enterprise Class Structure rule: rules are inherited downward from Organization to Division to Unit to Application to Case Type to Work Class; a rule defined higher is available to every descendant, so place rules at the highest class where they are universally valid.

Built On (pattern) inheritance carries rules from a reusable parent application; Directed inheritance (the Inherits From setting on a class) points at a single parent. Pattern inheritance is resolved before directed inheritance, and class group membership determines which rules are visible.

Rule resolution order: pattern inheritance, then directed inheritance, then the RuleSet list of the current application, then the ruleset version precedence (higher major.minor wins over lower; within the same version the highest patch applies).

Circumstancing precedence: a rule that matches more circumstance qualifiers wins over a less-qualified rule; a circumstance-qualified rule always beats the base rule regardless of ruleset position, so a base rule in a higher ruleset is still overridden by a qualified rule in a lower one.

Application stack: a built-on application's rules are available to the child, but the child's rules override the parent's; the class hierarchy, ruleset stack, and application stack are resolved independently and can produce different winners, which is a common source of unexpected behavior.

Data Pages are named, class-scoped, and loadable in Thread, Requestor, or Node scope; Node scope is shared across all requestors on the node and is the only scope suitable for large reference data; a Data Page's reload strategy (reload if older, reload once, etc.) controls staleness.

Case lifecycle stages (Create, Process, Resolve) map to the case type's work class; a stage transition is a flow, and the case type's primary stage gates which processes are available. Alternate stages and optional processes change the available path without altering the class structure.

Guardrail and performance rules: avoid activities in UI, prefer Data Transforms over activities for data mapping, keep declarative rules (Constraints, OnChange, Calculation) on properties, and use the Pega Platform's performance analyzer and guardrail compliance score to assess architecture quality.

Create the application with the Application Wizard: define the application name, the built-on application, the organization/division/unit, and the case types; the wizard generates the class structure, rulesets, and access groups that the rest of the build depends on.

Case Type rule: define stages, processes, and the work class; each stage contains a process (a flow) and optional alternate stages; the case type's data model is defined by the case's properties and the Data Types attached to it.

Data modeling: use Data Types (Data Objects) for reusable entities, map them to a class with a Data Transform, and expose them through Data Pages; a Data Type is not the same as a case type, and a case type can reference multiple data types.

UI build: Section rules are the reusable unit; Harness rules compose sections into the case's layout; use the Section's layout (dynamic layout, repeating layout) and configure actions through Flow Actions rather than hard-coded buttons.

Flow design: use a Process (flow) with assignments, decisions, and sub-processes; keep the main flow thin and move reusable logic into sub-flows or utilities; use the Flow's 'smart shape' palette and ensure every path reaches an end shape.

Validation and declarative rules: Constraints on properties enforce single-property rules; Edit Validate rules run on the server; OnChange and Calculation rules are declarative and fire automatically; use Validate rules for cross-property checks and keep them free of side effects.

Security build: configure Access Groups with roles, map roles to privileges, and use Access Control Policies (or the older Access of Role to Object) to control class-level and property-level access; attribute-based access control (ABAC) uses the Access Control Policy conditions.

Testing and deployment: use the Scenario Testing tool for unit-level case tests, run the application's guardrail report, and package changes into a product rule or a branch for deployment; verify the application stack and ruleset versions before promoting.