Pega Case Type Architecture Interview Questions and Answers
A Case Type is at the heart of Pega Case Management. It defines a repeatable business transaction and its lifecycle from initiation through resolution.
For a senior Pega interview, simply saying "a Case Type contains stages and processes" is not enough. The interviewer will usually continue with questions such as:
- Why did you make this a Case Type?
- Why is this a child Case?
- Why is this data on the Case instead of a Data Object?
- How do you handle an external system being unavailable?
- What happens to thousands of Cases already in production?
- How do you secure the Approve action?
- How do you prevent unnecessary Case persistence?
This article answers these questions from an architect's perspective using a practical Alpha Bank example.
The article covers Case lifecycle design, Stages, Processes, Steps, user and automated work, Data Pages, child Cases, SLAs, integration failures, in-flight Cases, ownership, authorization, and approval security.
In This Article
- How do you design a Case Type in a Pega banking application?
- What is a Case Type?
- When should something become a Case Type?
- When should something NOT become a Case Type?
- What is the difference between a Case Type and a Data Type?
- How do you design the lifecycle of a Case?
- How do you identify the stages of a Case?
- What is the difference between Stage, Process, and Step?
- How do you decide which activities should be user-driven versus automated?
- How do you design a Customer Onboarding Case?
- Walk me through your CustomerOnboarding Case Type.
- What would the lifecycle of CustomerOnboarding look like?
- What data would you keep on the CustomerOnboarding Case?
- What data would you retrieve from a Customer Data Object?
- How do you handle a Case that requires KYC verification?
- How do you handle a Case that requires AML screening?
- When would you use a child Case?
- How do you decide whether to use a child Case or a subprocess?
- How do you handle SLAs within a Case?
- How do you handle errors within a Case?
- How do you handle a Case that is waiting for an external system?
- How do you handle an integration failure in the middle of a Case?
- How do you handle a Case that has been sitting for several days?
- How do you handle changes to a Case Type when there are already thousands of Cases in production?
- How do you handle in-flight Cases when you deploy a new version?
- How do you prevent unnecessary writes to the Case?
- How do you design Case ownership?
- How do you design Case access versus Case action authorization?
- How would you secure the Approve action on a Loan Application?
1. How do you design a Case Type in a Pega banking application?
I start with the business outcome, not with the Pega flow. I identify the customer or business problem, the personas involved, the business data, the systems that provide or consume the data, the lifecycle, the decisions, the SLAs, and the possible exception paths. Then I model the Case using Stages, Processes, and Steps.
Architectural approach
- Identify the business outcome.
- Identify the Case boundary.
- Identify personas and ownership.
- Identify business data.
- Identify systems of record.
- Identify the primary lifecycle.
- Identify exception and alternate paths.
- Determine user versus automated work.
- Define SLAs and escalation.
- Define integration failure handling.
- Define security and authorization.
- Consider in-flight Cases before deployment.
Case Type Architecture
Example: Customer Onboarding
Customer Onboarding
|
+-- Capture Customer Information
|
+-- Verify Identity
|
+-- Perform KYC
|
+-- Perform AML Screening
|
+-- Risk Assessment
|
+-- Review / Approval
|
+-- Create Customer
|
+-- Complete Onboarding
The Case should coordinate the business journey while reusable Data Objects and integrations handle data access and external-system communication.
2. What is a Case Type?
A Case Type is an abstract model of a repeatable business transaction.
A Case is an individual instance of that Case Type.
For example, CustomerOnboarding is the Case Type and
ONB-12345 is a specific Case instance.
Case Type
CustomerOnboarding
|
+--------------------+
| |
v v
Case ONB-10001 Case ONB-10002
Pega defines a Case Type as an abstract model of a business transaction and a Case as a specific transaction instance.
What a Case Type defines
- Lifecycle
- Stages
- Processes
- Steps
- Data requirements
- Assignments
- Routing
- SLAs
- Case status
- Security
- Child Cases
- Automation
- Resolution behavior
3. When should something become a Case Type?
I make something a Case Type when it represents a meaningful unit of business work with its own lifecycle, ownership, processing, status, auditability, or resolution. The business should be able to describe the work as a transaction or journey from initiation to a meaningful outcome.
Strong Case Type candidates
- Customer Onboarding
- Loan Application
- Mortgage Application
- Dispute
- Fraud Investigation
- Account Opening
- Service Request
- Address Change Request
"Customer onboarding" is a good Case Type because it has:
- A beginning
- A business owner
- Multiple processing steps
- External verification
- Possible approvals
- SLAs
- Exception paths
- A final business outcome
4. When should something NOT become a Case Type?
I avoid creating a Case Type when the object is primarily business data, reference data, a simple calculation, a reusable service, or a small activity that does not require its own independent lifecycle.
Examples
| Requirement | Better model |
|---|---|
| Customer information | Data Object |
| Loan Product | Data Object |
| Calculate credit score | Decision / service / automation |
| Retrieve account balance | Data Page / Data Object |
| Send notification | Automation |
| Credit Bureau request | Integration / Data Page |
Do not create a Case Type for every noun in the business. "Customer", "Account", and "Loan Product" are usually business data. "Loan Application" represents work performed around those objects.
5. What is the difference between a Case Type and a Data Type?
| Case Type | Data Type / Data Object |
|---|---|
| Represents business work. | Represents business information. |
| Has a lifecycle. | Usually does not have a workflow lifecycle. |
| Can have assignments. | Normally provides data to Cases. |
| Can have SLAs. | Usually accessed through Data Pages. |
| Can be resolved. | Usually represents a record or business object. |
Example
Customer
|
+-- Data Object
|
+-- D_Customer
CustomerOnboarding
|
+-- Case Type
|
+-- Lifecycle
+-- Stages
+-- Processes
+-- Assignments
Pega Data Pages provide the bridge between Data Objects and Cases, allowing Cases to access data without depending directly on how the data is sourced.
6. How do you design the lifecycle of a Case?
I design the lifecycle from the desired business outcome backward. I identify the major milestones first, convert those milestones into Stages, then organize related work into Processes and individual user or automation activities into Steps.
Lifecycle Design
Then I identify alternate paths
+-- Reject
|
Create → Verify → Assess → Approve → Complete
|
+-- More Information
|
+-- Exception
Current Pega Case Lifecycle modeling supports Create, Primary, Resolution, and Alternate Stages, along with user-driven and automated Steps.
7. How do you identify the stages of a Case?
I identify Stages based on major business milestones, ownership changes, status changes, or meaningful phases of the Case lifecycle. A Stage should represent a meaningful section of work rather than simply a group of technical steps.
Customer Onboarding example
1. Intake 2. Verification 3. Compliance 4. Risk Assessment 5. Approval 6. Fulfillment 7. Resolution
A useful test is:
"This Case is in Verification." "When does this Case move to Approval?" "How many Cases are currently in Compliance?"
If the Stage name does not make sense in these sentences, reconsider the name. Pega Academy recommends business-meaningful Stage names and distinguishes Primary, Resolution, and Alternate Stages.
8. What is the difference between Stage, Process, and Step?
| Element | Purpose | Example |
|---|---|---|
| Stage | Major phase or milestone in the Case lifecycle. | Verification |
| Process | Logical grouping of related work within a Stage. | Verify Identity |
| Step | Individual user or automated action. | Collect ID information |
Stage: Verification
|
+-- Process: Verify Identity
|
+-- Step: Collect ID
+-- Step: Validate ID
+-- Step: Run Identity Check
Pega describes Stages as the top-level organization of Case work, Processes as groups of Tasks or Steps, and Steps as user or automated actions.
9. How do you decide which activities should be user-driven versus automated?
I automate deterministic, repeatable, system-driven activities and use user Assignments where human judgment, exception handling, investigation, or decision-making is required.
| Activity | Design |
|---|---|
| Collect customer information | User Assignment |
| Verify required fields | Automation / Validation |
| Call KYC service | Automation |
| Review KYC exception | User Assignment |
| Calculate risk score | Automation / Decisioning |
| Approve high-risk customer | User Approval |
| Send confirmation email | Automation |
I don't automate something simply because Pega can automate it. I automate where automation improves consistency, speed, or operational efficiency, while preserving human judgment where the business actually needs it.
10. How do you design a Customer Onboarding Case?
For Alpha Bank, I would model Customer Onboarding as a Case because it represents a complete business transaction that begins with an onboarding request and ends with either successful customer creation or a rejected/failed outcome.
Alpha Bank Customer Onboarding
Important design considerations
- Duplicate customer detection
- Identity verification
- KYC screening
- AML screening
- Risk classification
- Manual review
- Approval thresholds
- Customer creation
- Notifications
- Audit history
- SLAs
- Exception handling
11. Walk me through your CustomerOnboarding Case Type.
I would define CustomerOnboarding as the parent Case and keep the Case focused on coordinating the onboarding journey. I would retrieve existing customer data through Data Pages rather than copying the entire Customer record into the Case unnecessarily.
CustomerOnboarding
|
+-- Intake
| |
| +-- Capture Applicant
| +-- Check Duplicate
|
+-- Verification
| |
| +-- Identity Verification
| +-- Document Verification
|
+-- Compliance
| |
| +-- KYC
| +-- AML
|
+-- Risk Assessment
| |
| +-- Calculate Risk
| +-- Manual Review if Required
|
+-- Approval
|
+-- Fulfillment
|
+-- Create Customer
+-- Send Confirmation
Example Data Pages
D_Customer D_CustomerList D_KYCVerification D_AMLScreening D_CreditProfile D_CustomerAccount
Data Pages allow the Case to access data on demand and separate Case processing from data-source implementation details.
12. What would the lifecycle of CustomerOnboarding look like?
Primary Path
Alternate paths
+-- Identity Failed → Rejected
|
Create → Verify → Compliance → Risk → Approval → Fulfillment
|
+-- AML Alert → Manual Review
|
+-- Clear → Continue
|
+-- Reject → Rejected
The primary path should represent the normal business journey. Alternate stages can handle exceptions, negative outcomes, or recovery paths. Pega supports Alternate Stages for deviations from the primary path.
13. What data would you keep on the CustomerOnboarding Case?
I keep data on the Case when it represents information needed to drive the lifecycle, make decisions, display the current state of the transaction, or preserve an important business snapshot for audit purposes. I avoid copying large amounts of reference data onto the Case simply because the Case needs to display it.
Case data examples
CustomerOnboarding | +-- ApplicantID +-- OnboardingType +-- Channel +-- RequestedProduct +-- RiskCategory +-- KYCStatus +-- AMLStatus +-- ApprovalStatus +-- CurrentDecision +-- CaseOutcome
What I might not copy
- Entire Customer master record
- Large reference-data lists
- Static product catalogs
- Large external responses that are only needed temporarily
- Data that can safely be retrieved on demand
Persist information that is part of the Case's business state or required for audit. Retrieve reference or reusable information through appropriate Data Pages when possible.
14. What data would you retrieve from a Customer Data Object?
I would retrieve authoritative customer information from the Customer Data Object
when the Case needs current information from the system of record.
I would use a Data Page such as D_Customer rather than embedding
the system-of-record implementation into the Case.
Example
CustomerOnboarding
|
+-- CustomerID
|
v
D_Customer
|
v
Customer System
of Record
Possible Customer information
- Legal name
- Date of birth
- Address
- Contact information
- Customer status
- Existing customer relationships
- Customer risk information
The Data Page manages the data-source interaction and allows Case logic to remain independent from the underlying source.
15. How do you handle a Case that requires KYC verification?
I treat KYC verification as a business capability within the onboarding lifecycle. The Case invokes a KYC service through a Data Page or integration layer, evaluates the result, and routes the Case based on the business decision.
CustomerOnboarding
|
v
D_KYCVerification
|
v
KYC Service
|
v
+------------------------+
| Result |
| |
| PASS |
| FAIL |
| REVIEW |
+------------------------+
|
+-- PASS → Continue
|
+-- FAIL → Reject
|
+-- REVIEW → Manual Review
Architectural considerations
- Request and response mapping
- Timeout handling
- Retry strategy
- Audit requirements
- PII protection
- Service availability
- Manual exception path
- Duplicate request prevention
16. How do you handle a Case that requires AML screening?
I treat AML screening as a potentially asynchronous compliance process. The Case sends the screening request, stores the business-relevant result, and routes the Case based on the screening outcome. If the result requires investigation, I route the Case to a controlled manual-review path rather than allowing the normal onboarding path to continue automatically.
CustomerOnboarding
|
v
AML Screening
|
+-- CLEAR
| |
| +-- Continue
|
+-- REVIEW
| |
| +-- AML Investigation
|
+-- MATCH
|
+-- Compliance Decision
|
+-- Clear
+-- Reject
I would not simply add a Boolean property such as
AMLFailed = true and stop processing.
The architecture should explicitly model the business outcome, investigation,
ownership, auditability, and resolution path.
17. When would you use a child Case?
I use a child Case when a piece of work has its own lifecycle, ownership, security, reporting, persistence, or independent processing requirements. If the work is simply a small part of the parent's process and does not need its own identity or lifecycle, I normally use a subprocess instead.
Example
CustomerOnboarding may create separate child Cases:
CustomerOnboarding
|
+-- KYC Review Case
|
+-- AML Investigation Case
|
+-- Document Verification Case
Why child Cases can be useful
- Independent lifecycle
- Independent ownership
- Separate security boundary
- Independent persistence
- Independent reporting
- Parallel processing
- Separate SLAs
- Specialization
Pega's Case Processing guidance identifies child Cases as an option when independent processing, persistence, security, reporting, or locking characteristics are useful.
18. How do you decide whether to use a child Case or a subprocess?
| Question | Subprocess | Child Case |
|---|---|---|
| Needs independent lifecycle? | Usually no | Yes |
| Needs separate ownership? | Possible, but within parent processing | Strong candidate |
| Needs independent security? | Limited compared with separate Case | Strong candidate |
| Needs independent persistence? | No | Yes |
| Needs independent reporting? | Less suitable | Strong candidate |
| Simple reusable process? | Strong candidate | Usually unnecessary |
| Parallel work? | Possible | Strong candidate |
"Validate customer address" is probably a subprocess or automation.
"Investigate AML alert" may deserve a child Case because it has its own investigator, status, SLA, security, audit trail, and resolution.
Pega documents differences between subprocess and child-Case processing, including locking, security, persistence, reporting, specialization, and parallel processing.
19. How do you handle SLAs within a Case?
I start with the business commitment and determine the appropriate SLA level. I avoid putting independent SLAs everywhere because that can make prioritization and escalation difficult to coordinate.
Possible SLA levels
Case SLA | +-- Stage SLA | +-- Process SLA | +-- Assignment / Step SLA | +-- Approval SLA
Pega supports SLAs at Case, Stage, Process, and Step levels.
Example
| Level | Example |
|---|---|
| Case | Complete onboarding within 2 business days. |
| Compliance Stage | Complete compliance review within 8 hours. |
| KYC Assignment | Complete manual KYC review within 4 hours. |
I also define what happens at the Goal and Deadline:
- Increase urgency
- Notify owner
- Notify manager
- Escalate to work queue
- Reassign work
- Create an exception Case
Pega recommends considering all applicable SLA levels because multiple overlapping SLAs can increase complexity.
20. How do you handle errors within a Case?
I classify errors into business errors, user-correctable errors, transient technical errors, and permanent integration or configuration errors. Then I decide whether the Case should continue, retry, wait, route to an exception path, or stop.
| Error | Possible response |
|---|---|
| User entered invalid information | Display validation and allow correction. |
| External system timeout | Retry or wait. |
| External system unavailable | Retry and/or route to problem handling. |
| Invalid external response | Log, notify, and route to exception handling. |
| Business rejection | Follow an alternate business path. |
Pega provides connector error handling and error-handling flows for integration failures. The appropriate design depends on whether the error is transient, permanent, user-correctable, or requires Case processing to stop.
21. How do you handle a Case that is waiting for an external system?
I do not keep a user session waiting for a slow external system. If the response is asynchronous or can take an unpredictable amount of time, I design the Case to enter a waiting state and resume when the external event or response is received.
Example
CustomerOnboarding
|
v
Submit AML Request
|
v
Waiting for AML Response
|
+----------------------+
| |
v v
AML Response Timeout / Failure
| |
v v
Continue Retry / Exception
Architectural techniques
- Wait steps
- Asynchronous integration
- Callbacks
- Queue-based integration where appropriate
- Event-driven processing
- Case status indicating waiting state
- Timeout and retry strategy
A Case should be able to survive the wait. The architecture should not depend on a browser session remaining open.
22. How do you handle an integration failure in the middle of a Case?
First I determine whether the failure is transient or permanent. For transient failures I can retry using an appropriate retry strategy. For permanent failures I route the Case to an exception or problem-handling path, capture diagnostic information, notify the appropriate support or business team, and prevent the Case from silently continuing with incomplete data.
Integration Error Decision
Integration Call
|
v
Success?
/ \
YES NO
| |
v v
Continue Error Type
|
+--------+--------+
| |
Transient Permanent
| |
v v
Retry Log / Notify
| |
+-----+-----+ v
| | Exception Path
Success Failure
| |
v v
Continue Problem Handling
Pega's connector error-handling guidance recommends handling both transient and permanent errors. Connector error handling can include retry, logging, user notification, and problem flows.
Important Pega implementation concepts
- Error handling Data Transform
- Response Data Transform
- Error Handler Flow
- ConnectionProblem
- FlowProblems
- Retry Last Step
- Problem Flow handling
Pega's current error-detection guidance also describes pxErrorHandlingTemplate
as a reusable error-handling Data Transform template and provides error-handling flows
for connector failures.
23. How do you handle a Case that has been sitting for several days?
I first determine why it has been sitting. I look at Case status, current Stage, current Assignment, SLA status, urgency, owner, work queue, waiting conditions, and any integration or error state. I do not simply reassign or restart the Case without understanding the reason.
Investigation flow
Case sitting for days
|
+-- Assignment?
| |
| +-- Check owner / work queue
|
+-- SLA breached?
| |
| +-- Check escalation
|
+-- Waiting?
| |
| +-- Check external event
|
+-- Integration error?
| |
| +-- Check problem flow
|
+-- Case locked?
|
+-- Investigate locking / processing
Production techniques
- Case search
- Worklist / Work Queue analysis
- Case history
- SLA monitoring
- Problem Flow landing page
- Integration logs
- Alerting
- Reports on aged Cases
- Operational dashboards
Pega problem-flow handling provides mechanisms to investigate and resume Cases that encounter flow errors.
24. How do you handle changes to a Case Type when there are already thousands of Cases in production?
I never treat a Case Type change as affecting only new Cases. Before deploying the change, I identify all in-flight Cases and determine whether the change affects active assignments, wait points, stages, flow structure, routing, or data. Then I select an in-flight Case migration strategy and test it with existing Cases.
Dangerous changes
- Deleting an active Step
- Deleting a Stage containing active Cases
- Replacing a Step
- Changing internal flow structure
- Changing flow names or classes
- Removing wait points
- Changing routing assumptions
Pega documents that changes to active flow definitions can create orphaned assignments, problem flows, and stuck Cases.
Possible strategies
- Move existing assignments.
- Run old and new flow paths in parallel temporarily.
- Use an application-version strategy.
- Use dynamic class referencing where appropriate.
- Use circumstance/as-of-date approaches where appropriate.
The correct strategy depends on the nature of the change and the number and state of existing Cases.
25. How do you handle in-flight Cases when you deploy a new version?
I treat new Cases and in-flight Cases as separate populations. New Cases can use the new application or flow version, while existing Cases may need to continue under their original flow structure or be deliberately migrated. I never assume that an updated flow automatically makes every existing Case safe.
Strategy 1: Keep existing flow path
Old Cases
|
+-- Existing Assignment
|
+-- Old-compatible path
Strategy 2: Run old and new paths in parallel
+-- New Cases → NEW PATH
|
Application Update -+
|
+-- Existing Cases → OLD PATH
Strategy 3: Switch application version
Pega supports using an earlier application version for users processing in-flight Cases when the business requirement is to preserve the original application configuration.
Strategy 4: Move existing assignments
For a controlled population, existing assignments can be repositioned to a new location in the flow using an appropriate one-time migration or maintenance strategy. Pega documents this as one approach for handling in-flight Cases.
Always test the updated flow against existing Cases, not just newly created Cases.
26. How do you prevent unnecessary writes to the Case?
I minimize the amount of information persisted on the Case and avoid updating the Case simply to cache data that can be retrieved through a Data Page. I also avoid unnecessary property updates and unnecessary save operations. The Case should persist business state, not become a copy of every external system the Case interacts with.
Example
Instead of storing the complete Customer record on the Case:
CustomerOnboarding | +-- CustomerID | +-- D_Customer(CustomerID)
I can retrieve current Customer information when required.
Techniques
- Use Data Pages for on-demand reference data.
- Use appropriate Data Page scope.
- Persist only business-relevant Case data.
- Avoid repeatedly copying unchanged external data.
- Use savable Data Pages when controlled SOR updates are required.
- Batch or consolidate writes when the business process allows it.
- Avoid unnecessary activity-based database operations.
Pega Data Pages provide on-demand data access and caching, while Savable Data Pages provide controlled persistence through a data save plan.
Performance is not only about reducing database calls. It is also about deciding what data truly belongs to the Case and what data should remain in its authoritative system of record.
27. How do you design Case ownership?
I distinguish between Case ownership and assignment ownership. The Case can have a business owner responsible for the overall outcome, while individual assignments can be routed to users or work queues responsible for specific tasks.
Example
CustomerOnboarding | +-- Case Owner: Branch Operations | +-- Identity Verification → KYC Work Queue | +-- AML Review → AML Work Queue | +-- Approval → Manager | +-- Fulfillment → Operations Queue
Routing options
- Specific user
- Work Queue
- Skill-based routing
- Business logic
- Load balancing
- Manager hierarchy
I also consider what happens when:
- The owner leaves the organization.
- The Case exceeds its SLA.
- The Case is reassigned.
- The work queue is overloaded.
- The Case enters an exception path.
Ownership should represent business accountability. Assignment routing should represent who performs the current piece of work.
28. How do you design Case access versus Case action authorization?
I treat Case access and action authorization as two different security questions. First, I determine whether the user can access the Case. Second, I determine whether the user is authorized to perform a particular action on that Case.
Example
Loan Application
|
+-- Can Sarah open the Case?
| |
| +-- CASE ACCESS
|
+-- Can Sarah Approve the Case?
|
+-- ACTION AUTHORIZATION
Case access can involve
- Access Groups
- Access Roles
- Class permissions
- ARO / Access of Role to Object
- Access Deny
- Conditional access
- Case-level security design
Action authorization can involve
- Privileges
- Flow Action security
- Access Roles
- Case state / business conditions
- Approval authority
Pega's RBAC model distinguishes object-level access from privileges that authorize specific Rules or actions.
29. How would you secure the Approve action on a Loan Application?
I would secure the approval at multiple levels. First, the user must have access to the Loan Application Case. Second, the Approve action itself should require an appropriate privilege. Third, the Case should satisfy business conditions such as being in the correct Stage and status. Finally, the approval authority should be validated against the user's role, approval limit, and organizational rules.
Example security model
Loan Application
|
v
Can user access Case?
|
+-- NO → Deny
|
+-- YES
|
v
Is Case in Approval Stage?
|
+-- NO → Do not show / allow Approve
|
+-- YES
|
v
Has ApproveLoan privilege?
|
+-- NO → Deny
|
+-- YES
|
v
Is approval authority valid?
|
+-- NO → Deny
|
+-- YES
|
v
APPROVE
Implementation approach
1. Secure the Case
Use appropriate Access Groups, Access Roles, class permissions, and conditional access controls to determine who can access Loan Application Cases.
2. Secure the Approve action
Create a dedicated privilege such as:
ApproveLoan
Associate the privilege with the appropriate approval action/Rule. Pega supports privileges on Flow Actions and other Rule types to restrict who can execute specific functionality.
3. Grant the privilege only to appropriate roles
Loan Approver
|
+-- ApproveLoan privilege
For example:
| Role | ApproveLoan |
|---|---|
| Loan Processor | No |
| Loan Supervisor | Yes |
| Loan Manager | Yes |
4. Apply business conditions
Security authorization and business eligibility are not necessarily the same thing. A user may be an authorized approver but still be unable to approve a particular Case because the Case is not in the correct state or exceeds their approval authority.
Example approval matrix
| Loan Amount | Required Authority |
|---|---|
| Up to $25,000 | Loan Supervisor |
| $25,001 – $100,000 | Loan Manager |
| Above $100,000 | Senior Credit Authority |
The routing and authorization logic can be implemented using appropriate Pega decisioning and security mechanisms rather than relying only on UI visibility.
Hiding the Approve button is not sufficient security.
A user interface condition controls what the user sees. Authorization controls whether the operation is actually permitted. The server-side authorization model must enforce the business action.
Complete Case Type Architecture Blueprint
A senior architect should be able to visualize the complete Case architecture, not just the Case lifecycle.
ALPHA BANK
|
v
CUSTOMER ONBOARDING CASE
|
+--------------------+--------------------+
| | |
v v v
LIFECYCLE DATA INTEGRATIONS
| | |
| | +-- KYC
| | +-- AML
| | +-- Customer SOR
| |
| +-- Customer
| +-- Product
| +-- Identity
| +-- Risk
|
+-- Intake
+-- Verification
+-- Compliance
+-- Risk
+-- Approval
+-- Fulfillment
+-- Resolution
|
+------------+------------+
| |
v v
SLAs SECURITY
| |
+-- Goals +-- Case Access
+-- Deadlines +-- Privileges
+-- Escalation +-- Approval
+-- Routing +-- Roles
|
v
EXCEPTION HANDLING
|
+------------+------------+
| |
v v
Business Error Technical Error
| |
v v
Alternate Path Retry / Problem Flow
Child Case vs Subprocess: Quick Architecture Decision
| Requirement | Recommended direction |
|---|---|
| Small reusable process inside the same Case | Subprocess |
| Independent lifecycle | Child Case |
| Independent ownership | Child Case |
| Independent security boundary | Child Case |
| Independent reporting | Child Case |
| Simple calculation or service call | Automation |
| Reusable business information | Data Object / Data Page |
Case Data Design: What Belongs on the Case?
CASE
|
+--------------+--------------+
| |
v v
Business State Reference Data
| |
| +-- Data Pages
| +-- Data Objects
|
+-- Status
+-- Outcome
+-- Decision
+-- Customer ID
+-- Risk Category
+-- Compliance Status
+-- Approval Status
The question I ask as an architect is:
If it represents Case state, it may belong on the Case. If it is reusable/reference information, consider a Data Object and Data Page.
Case Lifecycle Design Rules for Interviews
| Rule | Architectural Guidance |
|---|---|
| Stage | Use for meaningful business milestones. |
| Process | Group related work within a Stage. |
| Step | Represent an individual user or automated action. |
| Automation | Use for deterministic system-driven work. |
| Assignment | Use when human action or judgment is required. |
| Child Case | Use when independent lifecycle or ownership is required. |
| Data Page | Use for reusable on-demand data access. |
| SLA | Apply at the appropriate Case, Stage, Process, or Step level. |
| Error handling | Design explicitly rather than allowing technical errors to stop the Case silently. |
| Security | Separate Case access from action authorization. |
| Production change | Always consider in-flight Cases before changing flow structure. |
What Interviewers Usually Ask Next
Once you answer the primary Case Type question, a senior interviewer may go deeper:
- Why is this a Case and not a Data Object?
- Why did you choose these Stages?
- Why is KYC a subprocess instead of a child Case?
- What happens if the AML service is unavailable?
- What happens if the Case waits for three days?
- Where is the customer data stored?
- Why are you copying customer information onto the Case?
- How do you prevent stale customer data?
- How do you handle 100,000 in-flight Cases?
- What happens if I delete an active Step?
- How do you migrate existing assignments?
- How do you secure the Approve button?
- Can a user open a Case but still be prevented from approving it?
- How do you handle SLA escalation?
- How do you troubleshoot a Case stuck in production?
Do not answer only with the Pega feature. Explain the business reason, the architectural choice, the implementation mechanism, and the production consequence.
How to Answer: "How Do You Design a Case Type?"
Interview-ready answer:
"I start by understanding the business outcome and defining the boundary of the transaction. I identify the personas, business data, systems of record, integrations, SLAs, decisions, and exception paths. Then I model the Case lifecycle using Stages, Processes, and Steps.
I keep the Case focused on business state and workflow and use Data Objects and Data Pages for reusable business data. I use automation for deterministic system work and Assignments when human judgment is required.
If a piece of work needs its own lifecycle, ownership, security, reporting, or independent persistence, I consider a child Case; otherwise I normally use a subprocess. For integrations, I design explicit error handling for transient and permanent failures. I also design SLAs and escalation from the business commitment rather than adding SLAs everywhere.
Finally, before deploying any Case Type changes to production, I evaluate the impact on in-flight Cases, especially active assignments and flow structure. For security, I separate Case access from action authorization and use privileges and appropriate roles to protect sensitive actions such as Loan Approval."
Final Takeaway
A well-designed Pega Case Type is more than a flow diagram. It is a complete business transaction model.
BUSINESS OUTCOME
|
v
CASE TYPE
|
+------------+------------+
| | |
v v v
LIFECYCLE DATA PERSONAS
| | |
v v v
Stages/Processes Data Pages Ownership
/Steps
|
+------------+------------+
|
v
INTEGRATIONS
|
v
ERROR HANDLING
|
v
SLAs
|
v
SECURITY
|
v
PRODUCTION CHANGE
|
v
IN-FLIGHT CASES
The strongest Pega architects do not simply ask, "How do I configure this Case?"
They ask:
That is the mindset expected when moving from a Pega developer role toward a Senior System Architect, Lead System Architect, or Principal Architect role.
Recommended Pega Topics to Study Alongside This Article
- Case Life Cycle
- Case Types and Cases
- Stages, Processes, and Steps
- Primary and Alternate Stages
- Resolution Stages
- Child Cases and Case Relationships
- Service-Level Agreements
- Routing and Work Queues
- Data Objects and Data Pages
- Savable Data Pages
- Connector Error Handling
- Problem Flows
- Role-Based Access Control
- Privileges
- Access of Role to Object
- Access Deny
- In-flight Case Management
- Application Versioning
References
- Pega Academy — Case Lifecycle
- Pega Academy — Case Lifecycle Design
- Pega Academy — Defining a Case Lifecycle
- Pega Academy — Case Processing
- Pega Academy — Service-Level Agreements
- Pega Academy — Data Pages and Visual Data Model
- Pega Academy — Savable Data Pages
- Pega Academy — Error Detection Configuration
- Pega Academy — Role-Based Access Control
- Pega Academy — Authorization Models
- Pega Academy — Handling Flow Changes for Cases in Flight
Pega Platform capabilities, terminology, and configuration screens can vary by Pega Platform release and application architecture. Always verify implementation details against the documentation for the specific Pega Platform version used by your project.
No comments:
Post a Comment