Live Data and data modeling

In the following video, the Solution Designer reminds the stakeholders about the necessary data customers must provide when opening a new account. The Solution Designer then shows the stakeholders the data structure in Blueprint, including the important distinction that what is seen in Blueprint is the Data Model design, and when the Solution Builder imports the Blueprint into Pega, the design transitions seamlessly to become the actual data structures that power the application.

The following video shows the Solution Designer walking stakeholders through configuring Pega Blueprint to reflect U+ Bank's requirements. The configuration keeps critical data in the bank’s system of record, outside of Pega applications.

The Solution Designer introduces a critical concept that shapes how U+ Bank's solution will work: "Not all data in your customer onboarding solution will be stored in Pega. Some data we'll store as part of the Case: application status, documents uploaded, and decisions made. But other data we'll access live from your existing systems of record."

The IT Director asks: "What's the difference? Why wouldn't we just pull everything into Pega?"

The Solution Designer explains: "Live Data is Pega's approach to accessing external systems in real-time without duplicating data. For example, when an existing customer starts a new account application, we don't store their customer profile in Pega—we access it live from your customer master system. When we need their credit score, we don't store it permanently; we retrieve it from the credit bureau at the moment we need it. When we check their existing account balances, we access your core banking system live."

The following image illustrates the difference between stored data and Live Data:

Understanding how Pega manages both stored and Live Data allows the Solution Designer to design efficiently while addressing any concerns or questions posed by stakeholders. The following video illustrates an example of this in the U+ Bank scenario, where design options can be explored collaboratively to ensure that what is implemented by the Solution Builder aligns with the organization's business rules and meets customer experience expectations:

The following image shows how the Customer Data Object acts as a template for capturing and storing customer information. Later, a Data Page can use the Customer ID to retrieve the customer details from the database.

The Solution Designer explains how Blueprint data models become Pega reality: "The data structure we're building in Blueprint—these data objects, the relationships between entities—becomes the actual data structure when the Solution Builder imports this into Pega. Everything we're designing together flows directly into implementation."

The IT Director asks: "So the Data Objects we're looking at in Blueprint are exactly what gets built in Pega?"

The Solution Designer clarifies: "The Data Objects and their structure—yes. The relationships between them—yes. What happens during implementation is the Solution Builder takes our Blueprint, imports it into Pega, and then configures the technical details we're not designing here—the Data Pages that connect to your external systems, the detailed validation Rules that ensure data quality, the integration points with credit bureaus and core banking systems."

This understanding enables confident design. The Solution Designer knows:

• Data Objects in Blueprint map directly to Pega Platform data objects: There is no translation gap
• Relationships between entities are maintained: A customer can have multiple accounts, each account can have multiple products, and Pega Platform manages those relationships
• Live Data connections are designed in Blueprint, implemented by Solution Builders: The Blueprint shows what external data is needed and when, while the Solution Builder configures the actual Data Pages and integrations

When the Solution Builder reviews the Data Model in the Blueprint, they see exactly what data structures to configure in Pega. If the Solution Builder asks, "How are we handling data from the credit bureau?" the Solution Designer can respond: "I've designed a Credit Data object in Blueprint with fields that map to the bureau's API response—credit score, payment history, open accounts, delinquencies. This is Live Data we'll access when needed, not stored data. You'll see in the Blueprint exactly where in the workflow we need credit data, and I've added notes indicating how this should be implemented in Pega."

This specificity in Blueprint—enabled by understanding Pega's data capabilities—removes ambiguity. Solution Builders do not guess about what data structures are needed or whether data should be stored or accessed live; they implement what the Solution Designer designed with full context about business requirements and technical approach.

Data modeling might seem like a technical concern, but it's fundamentally about understanding the business. The Solution Designer's Data Model in Blueprint captures U+ Bank's business reality, including customers, accounts, products, identity documents, credit information, and compliance data. By modeling this clearly in Blueprint with stakeholder validation and leveraging AI-generated sample data to make it tangible, the Solution Designer ensures the implemented solution will support the business processes stakeholders need.

The next topic explores how the Solution Designer designs the user interface in Blueprint using Constellation to create experiences that work beautifully for customers applying online, branch staff assisting customers, and underwriters reviewing applications, all from the same underlying data and workflow we have designed so far.