Pega Application Architecture – Part 2: Designing Case Types for the Nexus Banking Application
In Part 1, we designed the high-level architecture for Alpha Bank's Nexus banking application. Now we move one level deeper and design the most important building block of a Pega application: the Case Type.
Before creating a Case Type in Pega, we should first understand what business problem the Case Type represents. A Case Type should not simply be created because a business screen or database table exists.
A Case Type represents a repeatable business transaction or business journey that Pega manages from initiation through resolution.
For our Alpha Bank example, customers may open accounts, apply for loans, update their information, request cards, complete KYC verification, or report potentially fraudulent activity.
Each of these business journeys may become a separate Case Type when the organization needs Pega to manage its lifecycle, work, assignments, decisions, automation, SLAs, security, and auditability.
Pega Application Architecture – Part 2: How Case Types, Stages, Processes, Steps, Data, Personas, Business Rules, Integrations, and Security come together to implement a business transaction.
1. What Exactly Is a Case Type?
A Case Type is the reusable definition of a business transaction in Pega.
A Case is an individual instance created from that Case Type.
Case Type
The reusable definition or blueprint of the business transaction.
Case
A specific instance of that business transaction.
For example, Alpha Bank defines a LoanApplication Case Type. When John applies for a $250,000 home loan, Pega creates one Loan Application Case for John's request.
When Sarah applies for another loan, Pega creates a different Case instance using the same Case Type definition.
Case = Actual business transaction
2. Where Does the Case Type Fit in Nexus?
In Part 1, we established that Nexus is the banking application/product used by Alpha Bank.
Remember the important naming decision:
Alpha = organization namespace
Nexus = application/product name
Alpha-Banking-Work = class area where banking Case Types live
Therefore, our Loan Application Case Type can conceptually be represented as:
Notice that Nexus does not appear in the class name. That is intentional.
The application name and the class namespace solve different architectural problems. The application defines the application composition and ruleset context, while the class hierarchy defines inheritance and organizational ownership of rules.
3. Our Alpha Bank Case Types
Based on the banking capabilities established in Part 1, Nexus can contain several Case Types.
These are not simply screens. Each Case Type represents a business transaction with its own lifecycle, participants, data, automation, security, and resolution criteria.
4. When Should Something Become a Case Type?
One of the most important architecture decisions is deciding whether a business requirement should become a Case Type.
A useful question is:
If the answer is yes, a Case Type may be appropriate.
For example, Alpha Bank's Loan Application has:
- a start point
- customer and loan information
- document collection
- credit evaluation
- underwriting
- approval or rejection
- possible rework
- notifications
- SLAs
- audit requirements
- a final business outcome
This is a strong candidate for a Case Type.
On the other hand, a simple reference value such as a list of loan products should not automatically become a Case Type. That is data, not a business transaction.
5. Case Type vs Data Object
This distinction becomes extremely important as the application grows.
Case Type
Represents work or a business transaction.
Example: LoanApplication
Data Object
Represents business information used by one or more Case Types.
Example: Customer
The LoanApplication Case Type may use Customer, Account, Address, Employment, LoanProduct, Document, KYC, and CreditProfile data.
That does not mean those data objects should become child cases. They are data entities that support the business transaction.
6. Designing the Case Lifecycle
Once we decide that something is a Case Type, the next question is:
Pega models the Case Lifecycle using three major building blocks:
Major phase or milestone in the Case Lifecycle.
Logical group of related work inside a Stage.
Individual user or automated action.
7. Alpha Bank Example – Customer Onboarding
Let's design one of our most important banking Case Types: CustomerOnboarding.
The business requirement is simple:
We can model the Case Lifecycle at a high level as:
8. CustomerOnboarding – Detailed Lifecycle
9. Stage, Process and Step – Do Not Mix Them Up
A common mistake when learning Pega Case Management is treating Stage, Process, and Step as interchangeable terms.
Stage: Where are we in the overall business journey?
Process: What group of related work are we performing?
Step: What specific action needs to happen?
For example:
Process: KYC Review
Step: Validate Identity
Step: Review Documents
Step: Resolve Exceptions
10. User Steps vs Automation Steps
Not every Step in a Case requires a human.
A Case Lifecycle can contain both:
- User-driven work – an employee performs an action.
- Automated work – Pega or an external system performs processing.
For example, after Bob enters customer information, Nexus may automatically invoke a KYC service.
↓
Pega saves Case data
↓
Automated KYC verification
↓
KYC response returned
↓
Decision / routing
↓
Analyst assignment if required
This is one of the reasons Pega Case Management is different from simply building a collection of screens.
11. What Happens to the Case Data?
The Case Type needs information to execute the business process. That information can come from:
- data entered by the user
- existing customer information
- reference data
- external systems
- Data Pages
- decisions and calculations
- previous steps in the Case
This is where the Case Type connects to the Data Architecture we will cover in the next level of this series.
A Case contains the information needed to manage the business transaction, but that does not automatically make Pega the system of record for every piece of business data.
For example, Alpha Bank may maintain Customer information in an enterprise Customer Master system. Nexus can retrieve the required customer information and use it during onboarding without incorrectly making the Case the authoritative source for the customer's entire enterprise profile.
12. Case Type and Data Objects
Let's look at a practical Alpha Bank example.
├── Customer
├── Address
├── Contact Information
├── KYC Information
├── Documents
└── Risk Information
The Case Type defines the workflow. The Data Objects define reusable business information.
A Customer data object may be reused by:
- CustomerOnboarding
- AccountOpening
- CustomerMaintenance
- AddressChange
- LoanApplication
This reuse is one of the reasons we separated Work and Data in the architecture from Part 1.
13. Case Type and Integrations
A Case Type often needs information or services from external systems.
Consider the KYC process in CustomerOnboarding.
The Case Type should not contain all the technical details of the external API.
Instead, we maintain an integration boundary so that the Case process remains focused on the business outcome while the integration layer handles communication with external systems.
We will cover the Integration Architecture separately later in this series.
14. Case Type and Child Cases
Sometimes a business transaction contains another piece of work that deserves its own lifecycle.
For example, CustomerOnboarding might require:
- KYC Review
- Document Verification
- AML Review
The important question is not simply: "Can I create a child Case?"
The architecture question is:
If yes, a child Case may be appropriate.
If it is simply a small task within the parent business transaction, a Process or Step may be enough.
Avoid creating child Cases simply because a process contains several steps. Each Case introduces additional lifecycle, persistence, security, reporting, and operational considerations.
15. Case Type Class Structure
Now let's connect the Case Type back to the enterprise class structure we established in Part 1.
└── Alpha-Banking
└── Alpha-Banking-Work
├── CustomerOnboarding
├── AccountOpening
├── CustomerMaintenance
├── AddressChange
├── CardRequest
├── LoanApplication
├── FraudReview
├── KYCReview
└── AccountClosure
Conceptually, a Loan Application therefore belongs under:
This gives us a clean separation between the application's business workflow and reusable enterprise data or integration layers.
16. What Rules Actually Implement a Case Type?
From a developer's perspective, a Case Type is not just a visual diagram. Pega creates and uses multiple rule types and supporting artifacts to implement the behavior.
17. A Case Type Is More Than a Workflow Diagram
When designing a Case Type, we should think beyond the happy path.
For a real banking Case, we need to answer:
- Who starts the Case?
- Who works on it?
- What data is required?
- Where does the data come from?
- Which systems must be called?
- What happens if an integration fails?
- What happens if the customer provides incomplete information?
- Can the Case be rejected?
- Can the Case return for rework?
- What are the SLAs?
- Who can see the Case?
- Who can perform specific actions?
- What data must be protected?
- What needs to be audited?
- What happens if the process changes after Cases are already in flight?
This is where Case Type design becomes an architecture exercise, not just a low-code configuration exercise.
18. Case Ownership and Personas
A Case Type should identify the people or systems that participate in the business journey.
For Alpha Bank's LoanApplication:
Captures and reviews application information.
Reviews credit information and risk.
Performs approval activities according to authorization.
Provide credit, KYC, customer or other information.
This is also where our earlier security architecture becomes important. The Case Type defines the work, while Pega's security model determines who can access the Case and perform specific actions.
19. Case Access vs Case Action
These are two different security questions.
This separation is critical in a banking application.
A user may be allowed to open a Case but still not be allowed to approve it or view certain sensitive properties.
20. Case Type and SLAs
Real banking work is usually time-sensitive.
For example, Alpha Bank may define an SLA for:
- initial loan review
- KYC verification
- credit review
- manager approval
- customer response
The architecture should therefore consider SLA behavior while designing the Case Lifecycle instead of treating it as an afterthought.
We also need to distinguish between:
- time available for a Case
- time available for a specific assignment
- business calendar requirements
- escalation behavior
- what happens when the SLA is breached
21. Case Type and Error Handling
A production Case Type must also define what happens when something goes wrong.
Consider the following scenario:
The Case should not simply disappear or remain indefinitely waiting without an operational strategy.
Depending on the business requirement, the solution may include:
- bounded retry
- timeout handling
- technical failure status
- manual intervention
- queue-based retry
- notification to support teams
- audit information
This is why Case Type architecture must consider both the happy path and the failure path.
22. Case Type Runtime – What Actually Happens?
Let's follow John through the Nexus Loan Application process.
↓
Authentication
↓
Operator ID
↓
Access Group
↓
Nexus Application Context
↓
LoanApplication Case Type
↓
Case instance created
↓
Stage / Process / Step execution
↓
Data Pages / Data Objects
↓
Business Rules / Decisions
↓
Assignments / Flow Actions
↓
Integrations when required
↓
Case Resolution
This is the connection between the application architecture from Part 1 and the Case Type architecture in this post.
23. Case Type Architecture – Complete View
Stages / Processes / Steps
Personas / Users
Customer / Account / Loan
Decisions / Validation
External Systems
Case / Action / Data
Timing / Escalation
Audit / Monitoring / Recovery
24. Common Case Type Architecture Mistakes
A screen is not automatically a business transaction.
Customer or Account data does not automatically require a Case.
Use child Cases when independent lifecycle or ownership justifies them.
Do not turn the Case into the source of truth for every enterprise data entity.
Production Cases must handle timeouts, retries, exceptions and rework.
Hiding a button is not the same as securing the business action.
25. Rule-Level Mental Model
When troubleshooting a Case Type, I like to think about it in layers instead of looking at the Case Designer alone.
↓
Application Version
↓
Ruleset Stack
↓
Class Hierarchy
↓
Case Type
↓
Flow / Process
↓
Assignment / Flow Action
↓
Data / Decisions / Integrations
↓
Security / SLA / Audit
This mental model is especially useful when something works for one Case Type but not another.
26. Troubleshooting a Case Type
Suppose John says: "My Loan Application is not showing the next step."
Instead of immediately changing the UI, troubleshoot from the business and runtime layers.
- Confirm the Case Type being executed.
- Check the current Case stage and process.
- Check the current assignment and flow path.
- Verify the Case status.
- Check conditions controlling the transition.
- Check user authorization and role-based access.
- Check Access When / Access Deny or other security conditions where applicable.
- Check Data Pages and required data.
- Check integrations if the Case is waiting on an external system.
- Check SLA, queue or background processing if work is asynchronous.
Start with the Case's current runtime state and work backward through the rule and data dependencies. Do not assume that every Case Type problem is a UI problem.
27. Designing a Case Type – My Practical Approach
When I design a new Case Type for a banking application, I normally walk through these questions in order:
What are we trying to achieve?
What work belongs inside this Case?
What are the major Stages?
Who performs each activity?
What information is required?
Which external systems are required?
Who can access and act?
What happens when something fails?
28. Interview Question: Explain Case Type Architecture
Question: How do you design a Case Type in a Pega banking application?
Answer:
I start with the business outcome and define the boundary of the business transaction. For example, in Alpha Bank's Nexus application, LoanApplication represents the complete loan processing journey. I then model the Case Lifecycle using Stages, Processes, and Steps. Next, I identify the personas, Case data, reusable Data Objects, business rules, integrations, security requirements, SLAs, and exception paths.
From an architecture perspective, I keep workflow in the Work layer, reusable business data in the Data layer, and external communication behind the Integration boundary. I also make sure the Case is not incorrectly treated as the system of record for enterprise data.
Finally, I validate the security, performance, failure handling, audit, monitoring, and deployment implications before considering the Case Type production-ready.
29. Case Type Architecture – The Big Picture
Business Requirement
↓
Case Type
Defines the business transaction
↓
Case Lifecycle
Stages → Processes → Steps
↓
Data + Rules + Personas
↓
Integrations + Security + SLAs
↓
Business Outcome / Case Resolution
Key Takeaway
A Pega Case Type is not just a collection of screens or a workflow diagram. It is the model of a repeatable business transaction.
In our Alpha Bank Nexus architecture, a Case Type brings together the business lifecycle, people, data, rules, integrations, security, SLAs, exception handling, and final business outcome.
Once the Case boundary is correct, the rest of the architecture becomes much easier to design.
What's Next?
In the next level of our Pega Application Architecture series, we will move from Case Architecture into Data Architecture.
We will take the Customer, Account, Loan, Address, KYC and other Alpha Bank business objects and explain where they belong, how they relate to Case Types, how Data Pages provide access, and how we keep business data separate from workflow data.
No comments:
Post a Comment