Pega LSA key terms

A rule that defines the business structure of an application, including case types, data objects, and processes, and generates the underlying rules that implement that structure.

A rule that defines a business transaction end to end, specifying its data model, life cycle stages and steps, and the processes that move a case toward resolution.

The ordered set of stages a case passes through from creation to resolution, with each stage grouping the steps and processes that must complete before progression.

A phase within a case life cycle that collects the steps, processes, and decisions needed to reach a milestone, and controls when the case may advance.

A flow rule inside a stage or case type that sequences assignments, automations, and decisions; it may run as a subprocess or as a parallel path.

The collection of data objects and fields attached to a case type, defining what information the case carries and how that information is structured and referenced.

A reusable rule defining a structured set of fields, its relationships to other data objects, and how instances are sourced, saved, and referenced by cases.

A named, cacheable rule that loads and holds data for reuse across the application, with configurable scope, refresh strategy, and source of record.

A technique for defining variations of a rule that apply only when specified conditions, such as property values or date ranges, are true at runtime.

The engine that selects which rule instance applies to a request by evaluating applicability, inheritance, circumstance, and rule availability, then ranking candidates by class and ruleset.

A versioned container for rules that groups related behavior, controls which rule versions are deployed together, and is referenced by applications at a specific version.

A numbered snapshot of a ruleset with defined availability; versions move through development states such as open, locked, and available for deployment.

The top-level rule that assembles an application by listing the rulesets it uses, its built-on applications, and the class hierarchy it owns.

A parent application that supplies reusable rules, data types, and case types to a child application, enabling layered design and shared enterprise foundations.

The inheritance tree of classes that determines where rules are found and how they are inherited, from the base class down through work and data classes.

The mechanism by which a class or rule reuses definitions from its parent, allowing shared behavior to be defined once and specialized where needed.

A setting on a rule that controls whether it is active at runtime, such as available, blocked, withdrawn, or final, affecting rule resolution outcomes.

A pattern where an application's rules are defined in classes that sit directly beneath framework classes, so framework behavior is inherited without copying rules.

The class inheritance path derived from class name prefixes, used by rule resolution to search parent classes that share the naming pattern.

A packaged, reusable application built to be incorporated into other applications, typically providing shared case types, data types, or services.

A unit of work routed to a user or work queue that presents a form, holds the case while open, and completes when the user submits it.

A rule that defines the form and processing logic shown when a user completes an assignment, including the fields displayed and the actions available.

A routing destination that holds assignments for a group of users, from which individuals can pick up work based on skills, availability, or priority.

A rule that sets goals and deadlines for an assignment or case, triggering escalation actions such as notifications or reassignment when time thresholds are crossed.

A reusable UI rule that defines a portion of a form or page, composed of layouts and fields, and included by flow actions or other sections.

A container within a section that arranges fields and other sections visually, such as a grid, stack, or tabbed group, and controls responsive behavior.

A rule that evaluates a set of conditions against input properties and returns a result, used to express business logic in a tabular, easily maintained form.

A rule that evaluates a branching series of conditions to return a result, useful when logic is hierarchical rather than a flat combination of inputs.

A boolean condition rule that returns true or false based on property values or expressions, commonly used to control visibility, validation, and process branching.

The set of rules that check user input or case data against required conditions before an assignment is submitted, preventing invalid data from advancing.

A rule that performs a reusable format or pattern check on a single property value, invoked during validation of user input.

A rule that copies, maps, or computes values between properties and data objects, used to prepare data for display, persistence, or integration.

A rule that executes a sequence of steps, such as property assignments, method calls, and branching, typically used for procedural processing and integration logic.

The set of rules and connectors that exchange data with external systems, including REST and SOAP services, and the mapping between external and internal data models.

A rule that defines how to call an external system, specifying the endpoint, request and response mapping, authentication, and error handling behavior.

Execution of work outside a user's request, such as queue processors and job schedulers, used for asynchronous, bulk, or scheduled operations.

A rule that processes queued items asynchronously in the background, with configurable concurrency, retry, and error handling for reliable throughput.

A rule that runs an activity or queue processor on a defined schedule, used for recurring batch work such as data synchronization or reporting.

A design technique where business users maintain rules such as decision tables through a controlled interface, reducing dependency on developers for routine changes.