Pegasystems

Start here if Pega is new to you: how rules, cases, and the studios fit together, plus ready-to-copy blueprints — then rule types and rulesets, case lifecycles and assignments, and the App/Dev/Admin studios that build and run them.

Every Pegasystems term at a glance

Every entry, one line each. Highlighted ones have a detailed example below — click to jump there.

All 83 entries

Class: The container every rule is saved on — determines what it applies to
Class group: A concrete class grouping sibling work classes for reporting/database purposes
Pattern inheritance: Follows the class name itself, dropping the last segment
Directed inheritance: Explicitly set on a class rule, for reuse across unrelated hierarchies
@baseclass: The root class every other class ultimately inherits from
Ruleset: A named container of rules — the application's unit of packaging/migration
Ruleset version: major.minor.patch — a locked version cannot be edited
Ruleset list: An application's ordered rulesets — order affects rule resolution
Lock / unlock: Locking a ruleset version is what makes it migratable
Application rule: Defines the ruleset list and built-on application for an app
Built-on application: A prerequisite application whose rulesets this one extends
Property: A single piece of data on a class — the case type's fields
Page (clipboard): An in-memory instance of a class, holding property values at runtime
Category: Organizes rules within a ruleset for browsing, not for resolution
Decision Table: Rows of conditions across shared columns, first match wins
Decision Tree: Branching if/else logic for conditions that depend on each other
When condition: A single reusable true/false rule
Data Transform: Declaratively maps/copies/computes property values
Activity: An ordered list of procedural method steps — a last resort
Method step: One instruction inside an Activity, e.g. Obj-Save, Property-Set
Step page: The clipboard page a given Activity step operates on
Declare Expression: A forward-chaining rule that keeps a property always up to date
Declare Trigger: Runs logic automatically when an instance of a class is saved
Validate rule: Checks a page/property against business rules, independent of the UI
Edit Validate: Validates a single property value as it is entered
Edit Input / Edit Output: Transforms a property value on the way in/out of the clipboard
Function alias: Wraps a Java/utility function so it can be called like a rule
Report Definition: A declarative, joinable query rule — the reporting equivalent of an Activity
Data Page: A cached, reusable source of read-only data — a list or a single object
Case type: The definition of a unit of work — the top-level class of a case
Stage: A named phase of a case, shown as a visual progress indicator
Process (flow): A sequence of steps run within a stage
Step (case): One unit inside a process — an assignment, automation, or decision
Assignment: A unit of work waiting for an operator, queue, or external system
Flow action: The UI and logic for acting on an assignment
SLA (service level): Goal/deadline timers driving urgency and escalation
Urgency: A numeric worklist sort value that rises as a deadline nears
Worklist: An operator's personal queue of assigned work
Workbasket: A shared queue of assignments any eligible operator can claim
Sub-case: A child case spawned from a parent, tracked and resolved independently
Case status: The current lifecycle position, e.g. Open-InProgress, Resolved-Completed
Spin-off case: A related but independent case created without a parent-child link
Attachment: A file or note associated with a case
App Studio: The low-code studio for business-facing app design
Case Designer: Visual stage-and-process editor inside App Studio
Data Designer: Defines an app's data model — fields, records, relationships
Channel: Where the app is delivered — portal, mobile, email, chatbot
View: A user-facing screen, built from one or more sections
Section: A reusable group of fields and layout — the composable UI unit
Field (property): One piece of data with its own UI control on a view
Harness: The outer wrapper (header/footer/navigation) a UI renders inside
Live Data: A view that pulls in a Data Page for read-only display or selection
DX Component: A pre-built UI widget usable in App Studio without custom code
Dev Studio: The technical studio where rules, classes and rulesets are directly editable
App Explorer: A tree view of an application's own classes and rules
Records Explorer: Browses every rule on the system by type
Rule form: The editor for a rule — always headed by Applies To, ruleset, version
Rule resolution: The lookup Pega runs to pick exactly one rule from several candidates
Circumstance: A property-value-based variant of a rule
Specialization: A rule variant for a specific class, ruleset, or circumstance
Clipboard tool: Inspects live page/property state during a session, for debugging
Tracer: Step-by-step execution log for diagnosing what actually ran and why
Rule-Obj-Class: The rule type that defines a class itself
Operator ID: A user's login record and access group membership
Access group: Links an operator to an application and ruleset list
Access role: A named bundle of privileges, attached to an access group
Privilege: The smallest unit of permission a rule or UI element checks for
Requestor: A session's runtime context — one per user or service process
Node: One server instance in the cluster
Queue processor: Modern async/background processing, replacing most agent use
Agent: Legacy scheduled background processing, mostly superseded by queue processors
System Management App (SMA): Live dashboard for requestors, node health, and queue depth
PRPC log: The application server's underlying log, used for deep troubleshooting
Constellation: Pega's modern, browser-rendered UI architecture, built on Cosmos React and the DX API
Cosmos React: The component library Constellation UIs are assembled from
DX API: The REST API a Constellation front end calls to fetch view and component data
Deconstructed UI: UI and business logic split into independently versioned layers, not one server-rendered harness
Micro frontend: A portal assembled from independently deployable UI pieces rather than one monolith
Bootstrap shell: The first DX API call a portal makes — returns navigation, theme, and available portals
Component mapping: Matching a view-tree node's type to a registered Cosmos React component
Custom component: A self-registered component pack for cases no built-in Cosmos component covers
View (Constellation): A named component tree returned by the DX API and rendered client-side
Case Manager Portal: Pega's standard Constellation-based portal for working cases

Worked examples with live previews, for the parts worth seeing in action.

Starter Templates

How Pega Fits Together

If you’re coming from a typical web stack, the first surprise is that there is no local project to clone. You don’t run a scaffolding command, there’s no dev server on localhost, and there’s no folder of source files to open in an editor — Pega applications are built almost entirely inside Designer Studio, a web application that runs against a live Pega Infinity server. The “repository” is the platform’s own database, and the “build” is you clicking through rule forms in a browser.

Two studios sit inside that one browser app. App Studio is where most day-to-day design happens: case types, the stages and steps they move through, the fields a form shows. It deliberately hides the underlying structure. Dev Studio is where that structure — every rule, every class, every ruleset — is fully visible and directly editable; it’s what an application architect uses to lay the foundation App Studio later builds on top of.

Everything you create is a rule, and every rule lives in exactly one ruleset (the thing you package and migrate between environments) and applies to exactly one class (what kind of object the rule is even relevant to — an order, a customer, a case). A case type is really just a special class whose rules — its stages, processes, and steps — describe a unit of work from start to finish, and which App Studio lets you assemble visually instead of writing by hand.

The rest of this page is organized in roughly the order you’d meet these pieces building a first app: Rulesets & Classes and Rule Types cover the building blocks; Case Management covers assembling them into a unit of work; App Studio, Dev Studio, and Admin Studio cover where you go to do each kind of work; Constellation covers the newer UI layer cases are presented through. The Starter Templates in this category give you a shape to sketch out before you go build the real thing in Designer Studio.

The big picture before the details: where Pega development actually happens, and how rulesets, classes, and case types relate.

Designer Studio: Pega's own browser-based IDE — App Studio and Dev Studio are two views into it, not separate installs
Ruleset: The unit of packaging every rule belongs to — like a versioned package, not a folder of files
Class: What a rule applies to — a rule's class decides which case types and other rules can even see it
Case type: The definition of a unit of work, built from stages and processes rather than hand-written code

overview
designer studio
rulesets
case types
beginner

Case Type Blueprint Starter

Case Type: <Name>

Stage: <First stage>
  Process: <name>        -> Assignment: "<what the user does>"

Stage: <Second stage>
  Process: <name>        -> Assignment: "<what the user does>"

Stage: <Third stage>
  Process: <name>        -> Assignment: "<what the user does>"

Before opening App Studio, fill in this outline for your own case: a name for the case type, two or three stages it moves through, one process per stage, and at least one assignment step in each — the thing a real person has to actually do to move the case forward. Everything else (automations, decisions, sub-cases) can be added once this minimal shape exists and is recreated as an actual case type.

For the full picture of how stages, processes, and steps relate — including branching, SLAs, and non-assignment step types — see Case Lifecycle: Stages, Processes & Steps.

The minimal stage/process/step outline to sketch out before you start clicking through App Studio.

Sketch first: There's no file to paste this into — write it on paper or in a text editor, then recreate it by hand in App Studio's Case Designer
Stage: Name it after the phase of work, not the system action — "Review", not "Update Status"
Assignment: The one step type that stops and waits for a person — everything else can run automatically

case type
stage
process
boilerplate
beginner

Decision Table Blueprint Starter

Decision Table: <Name>
  <Condition column>     -> <Result column>
  <value/range>          -> <result>
  <value/range>          -> <result>
  (otherwise)            -> <default result>

Sketch this shape out first: name the table, pick one or two condition columns (the properties you’re testing), one result column, and always end with an (otherwise) row so a case that matches nothing still gets a sane default instead of a blank. Once this is on paper, recreating it as an actual Decision Table rule in Dev Studio is mostly filling in the same grid.

For a worked example with real columns, plus how Decision Trees and When conditions differ from a table, see Decision Tables, Trees & When Conditions.

The minimal condition/result shape to sketch out before creating a new Decision Table rule.

Condition column: One property being tested — keep it to one or two for a first table
Result column: What the rule returns when a row matches
Otherwise row: The catch-all last row — without one, a non-matching input returns a blank result

decision table
boilerplate
beginner

Data Transform Blueprint Starter

Data Transform: <Name>
  Set      .<Property>    to <value or expression>
  Set      .<Property>    to <value or expression>
  Apply    DataTransform   <OtherTransform>

Sketch this out first: name the transform, list two or three Set steps for the properties it needs to populate, and one Apply step calling another Data Transform for anything that’s already handled elsewhere (a defaults transform, a shared calculation). That’s the minimal shape to recreate in Dev Studio’s form — most Data Transforms in a real application are only slightly larger than this.

For the fuller shape (including looping over a page list) and where an Activity is actually still warranted, see Data Transforms & Activities.

The minimal set-steps-plus-apply shape to sketch out before creating a new Data Transform rule.

Set: The most common step — writes a literal or computed value onto a property
Apply: Calls another Data Transform, so shared setup logic can be reused instead of duplicated
Keep it declarative: If a step needs real branching or looping logic, that's usually a sign you need an Activity instead — see Data Transforms & Activities

data transform
boilerplate
beginner

First Access Group Checklist

A brand new application has nowhere for a user to land until three things exist, in this order:

An access group for the application — this is what links a logged-in operator to your app’s ruleset list. Without it, there’s nothing to log into.
At least one access role, attached to that access group, with the privileges your users actually need. An access group with no role attached lets someone log in but lets them do nothing.
An operator ID for each user, with that access group set as their default. This is the actual login record — username, password, and which access group they land in.

Do these out of order and the usual symptom is a user who can log in but sees a blank portal, or a login that fails outright because no access group is reachable. For how access groups, roles, and privileges compose once they’re already in place — including how the same case type can look different to different roles — see Access Groups, Roles & Privileges.

The minimum you need in place before a new operator can even log in and use your app.

Access group: Create this first — it ties an operator to your application and its ruleset list
Access role: Attach at least one to the access group before anyone logs in, or they'll see nothing
Operator ID: The actual login record — must reference the access group as its default

access group
access role
operator ID
checklist
beginner

Rulesets & Classes

Class Structure & Inheritance

MyCo-App-Work-Order        <- concrete class, actual case instances
MyCo-App-Work              <- pattern-inherits from here
MyCo-Work-                 <- base "Work-" pattern class (framework layer)
@baseclass                 <- root of everything

A rule saved on MyCo-App-Work is visible to MyCo-App-Work-Order and every other case type under MyCo-App-Work, but not the other way around.

Every rule lives on a class, and every class inherits from another — that chain decides which rules are even in scope.

Pattern inheritance: Follows the class name itself, dropping the last segment: MyCo-App-Work-Order to MyCo-App-Work
Directed inheritance: Explicitly set on the class rule — used to reuse rules across unrelated class hierarchies
Class group: A concrete class that groups its sibling work classes for reporting/database purposes

class
class group
pattern inheritance
directed inheritance

Rulesets & Ruleset Versions

MyCo-Framework    07-01-01   (locked, in production)
MyCo-App          03-02-01   (locked, in production)
MyCo-App          03-02-02   (unlocked, current dev version)

An application’s ruleset list determines which of these versions is even visible to a given requestor — and, when two rules with the same name exist in different rulesets, which one wins.

The unit of packaging and migration — every rule belongs to exactly one ruleset version.

Ruleset: A named container of rules — the unit you migrate/export between environments
Ruleset version: major.minor.patch — a locked version cannot be edited, only checked out into a new one
Ruleset list: An application's ordered list of rulesets — order matters for rule resolution
Lock / unlock: Locking a version is what makes it safe to migrate — unlocking is for active dev only

ruleset
ruleset version
ruleset list
lock
migration

Rule Types

Decision Tables, Trees & When Conditions

Decision Table: DiscountTier
  CustomerTier   OrderTotal      -> Discount
  Gold           >= 1000         -> 20%
  Gold           < 1000          -> 10%
  Silver         >= 1000         -> 10%
  (otherwise)                    -> 0%

When: IsHighValueOrder
  .OrderTotal > 1000 && .Priority = "Rush"

A When rule returns a plain boolean — the same IsHighValueOrder rule can drive a flow’s routing, a section’s visibility, and a validate rule, all at once, without duplicating the condition.

Creating your first Decision Table? Start with the plain Decision Table Blueprint Starter in Starter Templates — one or two columns and an otherwise row — before building the real thing in Dev Studio.

Three ways to express business logic declaratively, without writing a line of procedural code.

Decision Table: Rows of conditions across the same columns, evaluated top to bottom, first match wins
Decision Tree: Branching if/else logic — better than a table when conditions depend on each other
When condition: A single true/false rule, reused anywhere a condition is needed (visibility, validation, routing)

decision table
decision tree
when condition
declarative

Data Transforms & Activities

Data Transform: SetOrderDefaults
  Set        .Status         to "New"
  Set        .Priority       to "Standard"
  Apply      DataTransform    OrderDefaults.PricingRules
  Each row in .Items          Set .LineTotal to .Quantity * .UnitPrice

Activity: ProcessOrder
  Step 1   Applies to: Primary        Method: Data-Transform "SetOrderDefaults"
  Step 2   Applies to: Primary        Method: Obj-Save
  Step 3   Applies to: .Customer      Method: Property-Set

Pega’s own guidance is “activities as a last resort” — most of what an activity used to do now has a purpose-built declarative rule instead.

Writing your first Data Transform? Start with the plain Data Transform Blueprint Starter in Starter Templates — a couple of Set steps and an Apply — and grow it into something like SetOrderDefaults above once you need to.

Data Transforms shape data declaratively; Activities are the (increasingly discouraged) procedural escape hatch.

Data Transform: Maps/copies/computes property values — the preferred way to shape data, no code
Activity: An ordered list of method steps — used only where a declarative rule genuinely cannot do the job
Step page: The page (clipboard object) a given step in an activity operates on

data transform
activity
method
step page

Case Management

Case Lifecycle: Stages, Processes & Steps

Case Type: Order

Stage: Intake
  Process: Capture Details      -> Assignment: "Fill in order form"
  Process: Validate             -> Automation: "Check inventory"

Stage: Review
  Process: Approval             -> Assignment: "Manager review" (SLA: 1 day)

Stage: Resolution
  Process: Fulfill              -> Automation: "Send to warehouse"
  Process: Close                -> Utility: "Close case"

Stages run top to bottom by default, but can also branch or run alternately based on a decision — the visual stage view is what business users actually configure this in, via App Studio.

Building your first case type? Start with the plain Case Type Blueprint Starter in Starter Templates — three stages, one process each — and sketch it out before you open App Studio.

A case moves through stages; each stage runs one or more processes; each process is a sequence of steps.

Case type: The definition of a unit of work — an order, a claim, an application
Stage: A named phase of the case, shown to users as a visual progress indicator
Process (flow): A sequence of steps within a stage — assignments, automations, decisions, sub-cases
Step: One unit inside a process — an assignment, a utility, a collection of steps

case type
stage
process
step
flow

Assignments, Flow Actions & SLAs

Assignment: "Manager review"
  Flow actions available:
    - Approve   -> advances to Fulfill
    - Reject    -> advances to Rejected, notifies customer
    - Send back -> returns to Capture Details

SLA:
  Goal:      4 hours    (urgency starts increasing)
  Deadline:  24 hours   (escalates to the manager's manager)

An assignment on its own does nothing until a flow action runs — the flow action is where the actual case-changing logic (a Data Transform, a sub-process, a case-status change) is attached.

The work a person actually sees in their worklist, the actions available to them, and the clock running behind it.

Assignment: A unit of work waiting for an operator, a work queue, or an external system
Flow action: The UI + logic for what happens when someone acts on an assignment (approve, reject, ...)
SLA (service level): Goal and deadline timers — drives urgency, escalation, and reassignment
Urgency: A numeric value (0-100) that determines worklist sort order, and rises automatically as a deadline nears

assignment
flow action
SLA
worklist
urgency

App Studio

What App Studio Is For

App Studio is where most of an application’s day-to-day design work happens once the foundational architecture exists: adding a new case type, changing what a stage does, adjusting the fields on a form. It intentionally avoids showing rulesets, classes, or rule resolution — those decisions are assumed to already be in place, set up in Dev Studio by an application architect.

A team’s split is often exactly that: architects and senior developers work in Dev Studio to build the technical foundation, then business analysts and citizen developers extend it day-to-day in App Studio without needing to understand the class structure underneath.

The low-code studio built for business-facing app design — case types, views, and data, without touching a class hierarchy directly.

Case Designer: Visual stage-and-process editor — drag stages, add steps, no rule-form editing required
Data Designer: Defines the data model (fields, records, relationships) that case types run on
Channels: Where the app is delivered — web portal, mobile, email, chatbot — configured without separate rulesets per channel
App Studio vs Dev Studio: App Studio hides the class/ruleset layer entirely — Dev Studio is where that structure becomes visible and editable

App Studio
low-code
Case Designer
business user

Views, Sections & Fields

Views are assembled from sections, and sections are assembled from fields — the same section can be reused inside several different views, so a change to how “Customer Details” looks only has to happen in one place.

In App Studio this is mostly drag-and-drop: add a field, pick its control type, set whether it is required. The underlying rule this creates (a Section rule, technically a kind of “harness” content) is visible and editable directly in Dev Studio when finer control is needed than the App Studio UI exposes.

The building blocks of every screen a user sees — assembled, not hand-coded.

View: A user-facing screen — built from one or more sections
Section: A reusable group of fields and layout — the actual composable unit
Field (property): A single piece of data, bound to a property on the case, with its own control (text, dropdown, etc.)

view
section
field
layout

Dev Studio

Explorer, Records & the Rule Form

Dev Studio is where the class-and-ruleset structure that App Studio hides is actually visible and editable. Opening any rule form shows the same fixed header regardless of rule type: which class it applies to, which ruleset and version it belongs to, and its circumstance/specialization if any — that header is what rule resolution actually keys off of.

Most day-to-day work here is: find the rule (via App Explorer if it belongs to this application, Records Explorer if searching more broadly by type), open it, and edit the type-specific content underneath that shared header.

The technical studio — every rule, class, and ruleset is visible and directly editable here.

App Explorer: A tree view of the application's own classes and rules, organized by case type
Records Explorer: Browses every rule on the system by type (all Decision Tables, all Activities, ...), not just this app
Rule form: Every rule type opens in its own form — always with the same header: Applies To class, ruleset, and version

Dev Studio
App Explorer
Records Explorer
rule form

Rule Resolution

Looking up: Decision Table "TaxRate"  on class MyCo-App-Work-Order

1. MyCo-App-Work-Order   (exact class)          <- checked first
2. MyCo-App-Work         (pattern-inherited)
3. MyCo-Work-            (base pattern class)
4. @baseclass

At the first class where a match exists, apply circumstance:
  .Country = "DE"  ->  most specific circumstanced version wins
  (none match)     ->  base (uncircumstanced) version

If still tied, the higher ruleset in the application's ruleset list wins.

This top-to-bottom search is why the “wrong” version of a rule showing up almost always traces back to one of these three things: it was saved on the wrong class, a circumstance is not matching what is expected, or it is sitting in a ruleset lower in the stack than the one actually being used.

How Pega picks exactly one rule out of every same-named candidate across the class hierarchy and ruleset stack.

Class hierarchy: Checked first, most-specific class to least — a subclass rule always wins over a parent-class one
Circumstance: A property-value-based variant of a rule — e.g. a different tax rule per .Country
Ruleset stack order: Within the same class, the application's ruleset list order breaks any remaining tie

rule resolution
circumstance
specialization
ruleset stack

Admin Studio

Access Groups, Roles & Privileges

An operator ID belongs to one or more access groups; an access group grants one or more access roles; each access role bundles privileges. Checking “can this user do X” almost always resolves down to one privilege check, regardless of how many roles/groups were involved in granting it.

This layering is what lets the same application serve very different roles — a case worker and a manager can run the exact same case type, with different flow actions and buttons visible, purely from an access-role difference, with no change to the case logic itself.

Setting up a brand new app? See the First Access Group Checklist in Starter Templates for the minimal order to create these in so a new operator can actually log in.

The layers that decide what a logged-in user can actually see and do, independent of an app's rule logic.

Operator ID: A user's login record — which access group(s) they belong to
Access group: Links an operator to an application and a ruleset list — the entry point to everything else
Access role: A named bundle of privileges, attached to an access group
Privilege: The smallest unit — a single permission a rule or UI element can check for

access group
access role
privilege
operator ID

Requestors, Nodes & Queue Processors

Most “why is this one case stuck” investigations end up here rather than in the case’s own rules: a queue processor backed up, a node that is unhealthy, or a requestor that never released a lock. Admin Studio and the System Management App are where that runtime state is actually visible, separate from the application’s business logic entirely.

The runtime concepts behind "why is this slow" and "where does this background job actually run".

Requestor: A session's runtime context — one per logged-in user, or one per service/batch process
Node: One server instance in the cluster — a production system usually runs several
Queue processor: Modern async/background processing — replaced the older "agent" mechanism for most new work
SMA (System Management App): The live dashboard for requestor counts, node health, queue depth, and thread activity

requestor
node
queue processor
agent
System Management

Constellation

Constellation: The Deconstructed UI

Classic Pega UI (harnesses, sections, streams) has the server render HTML that the browser displays largely as-is. Constellation flips that: the browser holds a component tree built from Cosmos React, and that tree calls the DX API to fetch the data and view definitions it needs to render — closer to a modern single-page app than a server-rendered portal.

This is why Constellation apps are built almost entirely in App Studio: the view/component structure it produces maps directly onto this architecture, where a classic-UI section or harness does not.

Pega's modern front-end architecture — a browser-rendered component tree talking back to the server, instead of server-rendered HTML.

Cosmos React: Pega's own component library — the visual building blocks Constellation UIs are made of
DX API: The REST API a Constellation front end calls to fetch view/component data — the server no longer renders HTML directly
Deconstructed: UI and business logic are split into independently versioned layers, instead of one server-rendered harness
Micro frontend: Each portal/app assembles its UI from independently deployable pieces rather than one monolithic front end

Constellation
Cosmos React
DX API
micro frontend

Bootstrap Shell & Component Mapping

GET /application/bootstrap_shell
  -> { portals: [...], navigation: [...], theme: {...} }

POST /cases/{caseID}/views/{viewID}
  -> {
       type: "Region",
       children: [
         { type: "TextInput",  reference: ".CustomerName" },
         { type: "Dropdown",   reference: ".Priority" },
         { type: "Region",     children: [ ... ] }
       ]
     }

The bootstrap call runs once per session and shapes the portal shell itself; every subsequent view request returns a component tree like the one above, which the browser walks node by node — matching each type to a registered Cosmos React (or custom) component and passing it the named property reference to bind to.

The two DX API calls that get a Constellation portal from a blank browser tab to a rendered case view.

Bootstrap shell: The first call a portal makes — returns the app's navigation, theme, and available portals
Component mapping: Each node in a returned view tree names a Cosmos React component type — the browser looks it up and renders it
Custom component: A component pack you register yourself, for cases where no built-in Cosmos component fits

bootstrap shell
DX API
component mapping
view

webcheet

Pegasystems

The Pegasystems cheat sheet

Rulesets & Classes

Rule Types

Case Management

App Studio

Dev Studio

Admin Studio

Constellation

Every Pegasystems term at a glance

Starter Templates

How Pega Fits Together

First Access Group Checklist

Rulesets & Classes

Rule Types

Case Management

App Studio

What App Studio Is For

Views, Sections & Fields

Dev Studio

Explorer, Records & the Rule Form

Admin Studio

Access Groups, Roles & Privileges

Requestors, Nodes & Queue Processors

Constellation

Constellation: The Deconstructed UI