Building the Nexus Onboarding App with Pega Constellation UI: A Hands-On Walkthrough
When we started building the Nexus application for our fictional Alpha Bank, one of the first things we wanted to understand was not just what Pega Constellation is, but what it actually feels like to build an application with it.
So instead of starting with a theoretical explanation of Constellation, we built a real case type and followed the complete journey: Case Designer → Workflow → UX configuration → View configuration → Runtime.
This post walks through that experience using the Customer Onboarding case type in the Nexus application.
There is no custom React component in this example and no external UI framework being added on top of Pega. Everything shown here is being configured through the Pega application development experience and then rendered through the Constellation UI architecture.
What Exactly Is Pega Constellation?
If you are new to Constellation, the easiest way to understand it is to stop thinking about it as simply a new color scheme or a new screen design. Constellation is a newer Pega user experience architecture and authoring model. It changes how the UI is configured, represented, delivered and rendered, while the core Pega capabilities behind the application remain.
Pega describes Constellation around three major pieces:
1. Constellation Architecture
The application and UI architecture that favors configuration and a more prescriptive user experience.
2. Constellation Design System
Reusable UI components and interaction patterns used to render the experience.
3. Constellation DX API
Model-driven REST APIs that expose Pega case and assignment information together with UI metadata needed by the client.
The easiest mental model is:
↓
Constellation View
↓
Constellation Design System / Client
↓
User Experience
The Case is still a Pega Case. Stages are still stages. Steps are still steps. Data Objects, business rules, security, integrations, SLAs and routing still matter. The major change is the way the user experience is modeled and delivered.
Is a Constellation Application a Separate Pega Product?
No. This is one of the first things that confused me when I started working with it. A Constellation application still runs on Pega Platform. We are not creating a separate workflow engine or replacing Pega Case Management.
Think of it as:
↓
Case Management + Data + Rules + Security + Integrations
↓
Constellation User Experience Architecture
That distinction becomes important throughout this walkthrough.
What We Are Building
Before getting into the UI, it is important to understand what the application is supposed to do.
Alpha Bank Nexus is a workflow and process-orchestration application. It is not intended to replace the bank's systems of record. Instead, Nexus coordinates the customer onboarding process, collects the required information, performs verification and screening, routes the case, and manages human approvals.
For this walkthrough, our primary case type is:
Customer Onboarding
A simplified version of the business process looks like this:
- Capture customer information
- Capture application information
- Collect identity documents
- Obtain digital consent
- Verify identity
- Run KYC screening
- Run AML screening
- Perform risk assessment
- Review the results
- Route the case based on the outcome
- Obtain manager approval when required
The important point is that the UI is not being designed independently from the business process. The case lifecycle, the steps, the data model and the views are all connected.
Why Start with the Case Lifecycle?
When building a case type, it is tempting to immediately start creating fields and screens.
We took a different approach.
We first looked at the business lifecycle.
In Pega Case Designer, the workflow gives us a visual representation of how the case moves from one stage to another. This becomes the foundation for the rest of the application.
1. Designing the Customer Onboarding Lifecycle
The Customer Onboarding case type was created in Case Designer and organized into business-oriented stages.
The lifecycle shown in our application includes stages such as:
- Intake
- Verification
- Review
- Routing
- Approval
Within those stages, we have individual steps.
For example, the Intake stage contains:
- Collect Personal Info
- Request Digital Consent
- Acknowledge Submission
The Verification stage contains processing such as:
- Verify ID
- Run KYC Screening
- Run AML Screening
- Risk Assessment
- Summarize Screening
This is already telling us something important about the application. Not every step in a Pega case is necessarily a data-entry form.
Some steps are for people. Some steps perform processing. Some steps can call external systems. Some steps can make decisions. And some steps can use AI capabilities.
Yet they can all participate in the same case lifecycle.
Why this matters to an architect
This visual lifecycle becomes more than a configuration screen. It becomes a useful communication tool.
A business analyst can look at the lifecycle and understand the process. A developer can understand where processing occurs. A solution architect can identify where integrations, decisions, human assignments and approvals belong.
That is one of the practical advantages of designing the case around the business lifecycle first.
2. Moving from Workflow to User Experience
Once the lifecycle was established, the next question was:
What should the user actually see when they open the case?
This is where the UX configuration of the Case Designer becomes important.
Instead of immediately configuring every individual assignment, we first looked at the overall case page.
3. Configuring the Full Page View
The Full Page View controls the overall experience when a user opens a case.
In our Customer Onboarding case type, this area lets us configure things such as:
- The channel where the case is displayed
- The case heading
- The case subheading
- Highlighted fields
- Summary fields
- Available case tabs
The important thing here is the live preview.
While configuring the page, we can see how the changes affect the Constellation experience rather than having to guess what the final screen will look like.
For example
Suppose we decide that the customer name, customer type and current case status should be visible prominently.
We can configure those fields as highlighted or summary information and immediately see how they appear in the case experience.
This creates a much shorter feedback loop:
Configure → Preview → Adjust → Preview again.
That sounds simple, but it changes how the development team approaches UI design.
4. The Step-Level UI: Configure User Action
The next level is the actual screen used by a person while completing an assignment.
For example, our first major user-facing step is:
Collect Personal Info
From the case lifecycle, selecting the step and opening Configure User Action takes us into the step-level configuration experience.
The configuration screen is divided into areas such as:
- VIEW
- CONDITIONS
- PRE/POST-PROCESSING
For this post, the VIEW configuration is the most interesting part because this is where we define the actual user experience.
5. Designing the Collect Personal Info Screen
Our Collect Personal Info screen uses a two-column layout.
The screen contains information that the banker or onboarding analyst needs to capture before the case can continue.
The fields we configured include:
- Customer — reference to the customer data
- Application — reference to the application
- Identity document details — repeating information for identity documents
- Supporting documents received — boolean field
- Customer type — picklist
- Application submitted date — date field
One thing I found particularly useful while working with the View builder is that the fields are visually represented by their type.
For example, you can immediately distinguish a reference field from a boolean, picklist or date field without opening every field configuration.
That becomes increasingly useful as a view grows.
6. The Identity Document Table
One of the more realistic parts of the onboarding screen is the Identity document section.
A customer may provide more than one identity document, so representing this as a repeating structure makes more sense than creating separate fields for Passport, Driver License, National ID and so on.
Our screen exposes columns such as:
- Identity document type
- Identity document number
- Country of issuance
The user can add an identity document using the Add Identity Document action.
This is a good example of why the UI should follow the data model instead of the other way around.
If the business requirement says a customer can have multiple identity documents, the underlying data structure and the user experience should support that requirement naturally.
7. What Happens Under the Hood?
This is where it becomes interesting for Pega developers and architects.
Although we are designing the screen through Case Designer, the UI is still represented by Pega rule objects underneath.
For Constellation-based applications, the screen is represented as a
View, backed by a Rule-UI-View rule instance.
The user does not normally need to open and manually construct that rule through the traditional Dev Studio experience.
Instead, Case Designer provides the authoring experience.
The practical message here is:
Constellation changes the way we author the UI, but Pega still maintains rule-based application artifacts underneath.
That distinction is important.
As an architect, I don't want to think of Constellation as simply "another theme."
It represents a different UI architecture and authoring model.
8. What Is the Constellation DX API?
Once the word View starts making sense, the next question is: How does that View reach the browser?
This is where the Constellation DX API becomes important. It is a model-driven API layer used by the Constellation experience to work with Pega Cases and Assignments. The important idea is that the response is not just business data. The View can also be represented through UI metadata that describes how the client should understand and render the experience.
That is why the DX API is different from thinking about a traditional REST API as "give me some JSON data." The model contains information about the user experience as well as the Case information needed by the client.
↓
Constellation Client
↓
Constellation DX API
↓
Pega Platform
↓
Case + Data + View metadata
In our Pega instance, we can also select Preview as → DX API in the authoring experience. That preview gives us a structured representation of the View. It is useful evidence for understanding what Pega has modeled, but it should not be confused with the complete runtime HTTP request and response exchanged by the browser.
9. What Does the View JSON Tell Us?
In our actual CollectPersonalInfo View, the JSON representation contains
a View definition with a Fields region and component definitions. For example, the
View is associated with the Customer Onboarding class and uses a two-column
DefaultForm layout.
{
"CollectPersonalInfo": [
{
"config": {
"NumCols": "2",
"ruleClass": "Alph-Nexus-Work-CustomerOnboarding",
"template": "DefaultForm"
},
"name": "CollectPersonalInfo",
"type": "View",
"classID": "Alph-Nexus-Work-CustomerOnboarding"
}
]
}
Inside that View, the actual components include types such as:
- ObjectReference for Customer and Application
- EmbeddedDataMulti for Identity Document Details
- Checkbox for Supporting Documents Received
- Dropdown for Customer Type and other picklist values
- Date for Application Submitted Date
- TextInput for text properties in the data object
- Attachment for the document image
That is why I would not describe a Constellation View as simply "a screen." It is a structured model of the user experience: fields, components, layout, data bindings and configuration that the Constellation client can consume.
10. The Data Binding Is Part of the Story
The Customer field in our actual View is represented as an Object Reference. The JSON identifies the target object class as:
The Application field similarly references:
This is important architecturally. The View is not treating every control as an isolated visual widget. The UI is connected to the application's data model.
11. Where Does React Fit?
Another common question is: "If Constellation uses React, do I now need to be a React developer to build Pega applications?"
For a standard Constellation application, the answer is not necessarily. Pega provides the standard design system, components and authoring experience. A Pega developer can configure the normal application experience without manually writing the entire front end.
React becomes more important when a team goes beyond the standard experience, for example when building custom Constellation DX components or a custom front end that consumes the DX API.
Normal Constellation development
Case Designer / App Studio → View configuration → Constellation components → UI
Custom UI extension
React → Custom Constellation DX Component → Pega Platform
Custom front end
React / another front-end technology → Constellation DX API → Pega Platform
12. Traditional Pega UI vs Constellation
| Traditional UI | Constellation |
|---|---|
| Section-based UI authoring | View-based UI authoring |
| Greater freedom for UI customization | More prescriptive, configuration-first experience |
| Traditional DX API patterns | Constellation DX API and View metadata |
| Sections and layouts | Views and Constellation components |
This is not a statement that traditional UI is "bad" and Constellation is "good." They are different UI architectures with different capabilities and trade-offs. For existing applications, the current architecture and requirements should be considered before making a change.
13. Design Time vs Runtime
At this point we have configured the screen.
But the real test is not the preview.
The real test is:
What does a user actually see when the case runs?
So we created and opened a live case.
14. The Live Nexus Case
The following screenshot shows a running case in the Constellation experience.
The running case presents the user with a complete case workspace.
At the top, the user can see the case title and current work status. The lifecycle is represented visually across the page, allowing the user to understand where the case currently sits in the overall process.
In our Risk Assessment example, the case shows stages including:
- Intake Review
- Screening Checks
- Risk Analysis
- Case Routing
- Case Approval
Below the lifecycle, the user can see the current assignment.
The assignment includes a Go action that takes the user into the actual work screen.
15. Opening the Assignment
Now comes the part that I think demonstrates Constellation best.
We configured the Collect Personal Info view in Case Designer.
We then opened the live assignment.
The runtime screen now contains the same concepts we configured during design time:
- Customer
- Application
- Identity document details
- Supporting documents received
- Customer type
- Application submitted date
The two-column layout is also reflected in the actual assignment.
This is the part worth paying attention to:
We did not separately build another screen for runtime.
The screen we configured in the Case Designer becomes the experience the user works with when the assignment runs.
16. The Design-to-Runtime Loop
This is probably the biggest practical difference we noticed while building this example.
The development loop is very direct:
Business requirement → Case step → View configuration → Preview → Run case → Validate with user
If a field needs to move, we can change the view.
If another field needs to be displayed, we can add it.
If the business process changes, we can change the lifecycle.
That creates a much tighter relationship between the process model and the user experience.
17. Where Does Dev Studio Fit?
This does not mean Dev Studio has disappeared.
Dev Studio remains important for deeper application development, architecture, security, integrations, rules, troubleshooting and other platform capabilities.
The important distinction is that we don't necessarily need to start with Dev Studio to build every piece of the user interface.
For Constellation applications, Case Designer becomes the natural authoring surface for the case experience.
That is especially useful when business-facing team members and application developers need to work together on the same case design.
Why Would We Use Constellation?
For this Nexus learning application, the biggest reason is not that the old UI cannot build the process. The reason is that we want to understand the newer Pega UI architecture and the configuration model it provides.
- Configuration over unnecessary customization: standard components and Views provide a consistent path for common UI requirements.
- Consistency: common interaction patterns can be used across Case Types.
- Maintainability: less unnecessary custom UI behavior can mean less UI-specific code to maintain.
- Modern client architecture: the experience is designed around a modern single-page application model.
- API-driven experiences: the Constellation DX API creates a clear separation between business capabilities and presentation channels.
- Reusable patterns: Views and standard components give teams a common way to build case experiences.
At the same time, Constellation is intentionally more prescriptive. If a requirement cannot be met cleanly with the standard components, the team should understand the extension options and the additional maintenance and upgrade considerations before adding custom UI.
What Pega Provides vs What We Configure
| Pega provides | We configure |
|---|---|
| Case management engine | Case Types and lifecycle |
| Constellation architecture | Business process and stages |
| Constellation Design System | Views, fields and layouts |
| Constellation DX API | Data model and relationships |
| Standard UI components | Business rules, routing, security and integrations |
Constellation and Center-out Thinking
The Constellation approach also fits naturally with a center-out way of thinking: keep the enterprise business capability in the platform and allow different presentation channels to consume that capability rather than rebuilding the same business logic independently in every channel.
Business process + data + rules + security + integrations
↓
DX / Application Services
↓
Constellation UI Mobile Custom Front End
13. Why We Are Building Nexus This Way
The Nexus application is being built as an architecture demonstration, not just as a collection of screens.
So every configuration decision should eventually answer a bigger question:
Why would we design an enterprise Pega application this way?
For example, the Customer Onboarding case will eventually need to interact with customer data, KYC, AML, risk assessment and potentially other banking systems.
We don't want the UI to become responsible for that integration logic.
Instead, the architecture should separate:
- User experience — what the user sees and enters
- Case workflow — how the work moves
- Business rules — how decisions are made
- Data model — what information the case uses
- Integration layer — how external systems are accessed
- Security — who can see and perform the work
That separation will become increasingly important as we continue building Nexus.
14. What We Have Built So Far
At this point in the Nexus build, we have already moved beyond simply creating an application shell.
We have a real case type with:
- A defined business lifecycle
- Multiple stages
- Human assignments
- Automated processing steps
- Risk assessment processing
- Review and routing activities
- Approval processing
- A configured Constellation case experience
- A step-level user interface
- Repeating identity document information
- Data references
- Picklist and date fields
- A live case that can be executed and tested
That gives us a foundation for the next parts of the application.
15. What We Should Build Next
The next step should not be jumping immediately into complex REST failure scenarios.
The application is not at that point yet.
Instead, we should continue building Nexus in the same order that a real enterprise application would evolve.
Next: Data Architecture
The next important question is:
Where do Customer, Application, Identity Document, Account, KYC and Risk Assessment data actually live?
We can use that discussion to introduce Pega Data Types and the relationship between case data and enterprise data.
For example:
Customer Onboarding Case
|
+-- Customer
|
+-- Application
|
+-- Identity Documents
|
+-- KYC Information
|
+-- AML Result
|
+-- Risk Assessment
|
+-- Approval Decision
Once the data model is clear, we can start introducing Data Pages and eventually external systems.
Then: Business Rules
After the data structure is established, we can implement actual business behavior.
For example:
- Customer type determines required information
- Missing identity documents prevent submission
- Risk score determines routing
- High-risk cases require additional review
- Certain screening results require manager approval
That gives us a natural place to demonstrate validations, decision tables, decision trees, When rules and other Pega rule types.
Then: Security
Once we have real work and real personas, security becomes much easier to demonstrate.
For example:
- Customer service users can create onboarding cases
- Analysts can perform verification
- Risk analysts can perform risk assessment
- Managers can approve high-risk cases
- Compliance users can access screening information
Now we have an actual reason to demonstrate Access Groups, Roles, Privileges, AROs and case-level security.
Finally: Integrations
Once the data, workflow, business rules and security are established, we can move into the REST integration scenarios we originally discussed.
At that point, those scenarios will no longer be artificial examples.
We will have a real Nexus flow that can call:
- Customer systems
- KYC services
- AML services
- Credit/risk services
- Document management
Then we can deliberately introduce conditions such as timeouts, HTTP 500 errors, business errors, retries, duplicate requests, authentication failures and large responses.
That will give us genuine implementation evidence for the integration articles.
Key Takeaways for Pega Architects
- Start with the case lifecycle. The workflow gives the application its business structure before we start worrying about individual screens.
- Think about the case experience as a whole. The Full Page View controls the overall case workspace, while individual steps have their own views.
- Use Case Designer for Constellation UI authoring. The modern experience is centered around Views rather than the classic section-centric approach.
- Keep UI and business processing separate. The screen collects and presents information; the case architecture should determine what happens with that information.
- Use the live preview. The ability to see the view while configuring it makes UI iteration much faster.
- Always validate at runtime. A design-time preview is useful, but the actual case execution is where we confirm the complete user experience.
- Build the architecture in layers. Data, workflow, business rules, security and integrations should evolve together rather than putting everything into the UI.
Final Thoughts
After building this part of Nexus, the biggest takeaway for me is that Constellation is easier to understand when you stop looking at it as simply a new Pega UI.
The more useful way to look at it is as a different application development experience where the case lifecycle, views and runtime experience are much more closely connected.
We started with a business process.
We turned that process into a case lifecycle.
We configured the case experience.
We built the user action view.
And then we opened a real case and saw the same design running for the user.
That is the part that matters.
The next step for Nexus is not another isolated demo. We will continue from this working application and add the data architecture, business rules, security and integrations one layer at a time.
And as we build each layer, we can document the actual Pega configuration, runtime behavior and lessons learned.
No comments:
Post a Comment