Quick definitions for the acronyms and terms that come up constantly in Pega work and interviews — each one links to where it's covered in depth.
RBACRole-Based Access Control
Access decisions based on the role a user is assigned — what job functions and access roles allow you to do.
See Security posts →ABACAttribute-Based Access Control
Finer-grained access decisions based on attributes of the user, the case, or the data itself — not just their role.
See Security posts →SAMLSecurity Assertion Markup Language
The standard used to pass authentication and identity information between an Identity Provider and Pega during Single Sign-On.
See Security posts →SSOSingle Sign-On
Letting a user log in once with an external Identity Provider and access Pega without a separate username/password.
See Security posts →IdPIdentity Provider
The external system (like Okta or Azure AD) that authenticates a user's identity and hands Pega a trusted assertion about who they are.
See Security posts →AROAccess Role to Object
The rule that maps a specific access role to what it can actually do to a given class of objects — read, update, delete, and so on.
See Security posts →Access Group
Ties an operator to the roles, application, and rulesets they can use — the central hub that decides what a logged-in user is allowed to see and do.
See Security posts →Operator ID
Pega's representation of an individual user account — their login, profile, and the access group(s) they belong to.
See Security posts →Privilege
A named permission that a rule (like a flow action or a button) can require before it's allowed to run for a given user.
See Security posts →Case Type
A template that defines the stages, steps, and data a particular kind of work item follows from creation to resolution.
See Case Management posts →Flow Action
A user-facing action — like Approve or Reject — that lets someone move a case forward or capture data at a step in the flow.
See Flow Actions posts →Case Locking
How Pega prevents two users from editing the same case at once — who holds the lock, and what happens when it's released or times out.
See Case locking posts →GetNextWork
The logic Pega uses to decide which assignment a user sees next in their worklist — priority, routing, and availability all factor in.
See GetNextWork posts →Parallel Processing
Running multiple branches of a case's work at the same time instead of strictly one step after another — and reconciling them when they finish.
See ParallelProcessing posts →Background Process
Work that runs without a user waiting on it — queue processors, job schedulers, and other automated case-handling that happens behind the scenes.
See Background Process posts →Ruleset
A named, versioned container for a group of rules — the basic unit Pega uses to organize, package, and migrate an application's logic.
See Ruleset posts →Rule Resolution
The process Pega uses at runtime to pick the single correct version of a rule out of every version available in the class and ruleset hierarchy.
See Rule resolution posts →Circumstance
A way to create a specialized version of a rule that only applies under a specific condition, without duplicating the whole rule.
See Rule resolution posts →Activity
A sequence of steps written in Pega's own scripting language to carry out server-side logic — one of the oldest and most flexible rule types.
See Activity posts →Data Page
A reusable, cacheable source of data — from a database, an integration, or a fixed list — that other rules can reference without refetching it every time.
See Data Page posts →Data Transform
A rule that maps and reshapes data from one structure into another — commonly used to prepare data for an integration or a UI.
See Data Transform posts →GRSGlobal Resource Setting
A mechanism for managing environment-specific configuration values (like URLs or credentials) separately from the application's rules.
See GRS posts →Delegation
Letting a business user (not a developer) safely edit certain rules — like decision tables — within guardrails the developer sets up in advance.
See Delegation posts →KYCKnow Your Customer
The identity-verification and due-diligence process banks run on customers — frequently modeled as its own case type in Pega banking applications.
See the Architecture series →AMLAnti-Money Laundering
Screening and monitoring processes designed to detect suspicious financial activity — another common integration point in banking case designs.
See the Architecture series →