Shape the Data Model from business intent
A well-designed Data Model gives a Case Type the data it needs to achieve and explain its outcome. It identifies the business entities involved, the data required to identify and describe them, the relationships among them, and the data created as work progresses.
Pega Blueprint™ has already generated a first interpretation from the available application context. The Case Data Model and View Relationships provide the working environment in which stakeholders and the Solution Designer review that interpretation, clarify its business meaning, and shape it into a more complete representation of the Case outcome.
This topic establishes a high-level view of the data the Case Type needs. The aim is to understand the principal business entities, Case data, relationships, and open questions before defining Fields and reusable structures in detail.
Analyze data and integration needs in stakeholder language
Stakeholders describe the information they use, create, exchange, and retain without separating it into Fields, Data Objects, references, sources, or integrations. The Solution Designer interprets that account and determines how the information should be represented in the design.
Elena’s account
“For every booking, the team needs to know which tour the customer selected, when the tour will take place, who will participate, and whether the booking can proceed. Some information belongs only to the booking, while information about tours, customers, and equipment already exists elsewhere. We also rely on weather and tide information when deciding whether a tour is viable. Partners sometimes submit new bookings or changes through their own systems, and accepted customer updates may need to be retained beyond the current booking.”
Elena’s account reveals several connected design needs. Tour Booking creates and uses booking-specific information. The Case also relies on reusable business information that may already exist, values supplied by external capabilities, changes that may need to persist beyond the Case, and events that may begin outside the application.
Evaluate the stakeholder account
Use the following questions to separate the information in the stakeholder account before representing it in the design:
- Which information describes this Tour Booking?
- Which information describes a reusable business entity?
- Which information already exists outside the application?
- Which values or results are created as the Case progresses?
- Which external interactions create, update, or support the Case?
- Which Decisions depend on information that must be current, trusted, and available?
Tip: Begin with the business account. Separate meaning, placement, source, interaction, and continuity before selecting the Blueprint structures that represent them.
The five connected Data and Integration Design decisions
The following figure shows the five connected Data and Integration Design decisions used to evaluate meaning, placement, source, interaction, and continuity:
Identify the business data behind the Case Design
Establishing the business Data Model starts by understanding the data entities and attributes the business uses to process work, together with the relationships between those data elements. This gives stakeholders and the Solution Designer a shared business view of the data required by Tour Booking.
For Tour Booking, the first pass may identify:
- Tour, the offering selected for the booking;
- Traveler, a person taking part in the booked Tour;
- Payment Transaction, a financial event associated with the booking;
- Customer Feedback, information created through the booking journey or used by a wider feedback capability.
- The following business-entity view shows these entities and their principal relationships to Tour Booking. It gives stakeholders a visual basis for identifying gaps before the team reviews how Blueprint has represented the business intent.
These entities are already represented through Blueprint’s Pega Data Modeling capabilities. Treat their current names, descriptions, Fields, and relationships as proposed definitions that will develop as the business understanding becomes clearer.
Aim to establish as comprehensive a first definition as the available business understanding allows. At this stage, confirm:
- Which business entities Tour Booking needs to recognize
- Which data identifies and describes each entity
- Which data the Tour Booking Case Design creates
- Which relationships are required to support the outcome
- Which design questions remain open for stakeholder or technical clarification
Use the Case Design to test this first definition. Determine Tour Viability, for example, brings together Selected Tour, Tour date and time, Traveler data, operating conditions, and the Business Rules that evaluate them. Tracing those dependencies reveals the data needed to reach, explain, and act on the Decision.
Tip: Give Blueprint enough business context to create a useful starting interpretation. Use stakeholder language, source material, and the Case outcome to describe each proposed entity clearly. Review the AI-generated Fields and relationships with stakeholders, then refine the definition as the business understanding develops.
Tip: Involve people who understand the organization’s established data definitions and responsibilities. A data modeler, data architect, database administrator, or relevant system owner can help identify existing definitions, clarify ownership, and reveal reuse or integration considerations early in the design.
Review and refine the model in Blueprint
Use Blueprint’s developing representation to continue the stakeholder discussion. Retain choices that express the business intent, refine unclear meaning, and add missing concepts revealed by the Case Design.
Use View Relationships to orient the discussion
View Relationships shows the Data Objects and other structures Blueprint has associated with Tour Booking. Use the connected view to discuss:
- Which business entities Blueprint has recognized
- How Tour Booking appears to depend on them
- Which expected relationships are present
- Which generated dependencies need further explanation
- Which business concepts required by the Case outcome are not yet visible
For Tour Booking, the generated view may include Customer Account, Tour, Payment Transaction, Customer Feedback, Equipment, and Tour Guide. Treat these as starting suggestions. Confirm the purpose of each proposed structure and remove or refine choices that do not support the selected outcome.
Review and refine how Blueprint has represented each business concept
Use the Case Data Model to examine the Fields and relationships behind the connected view. Blueprint can place several related Fields directly on Tour Booking even when some describe a reusable business entity.
Tour provides a practical example. Tour category, location, duration, Standard capacity, and operating requirements describe the reusable Tour offering. Tour date and time, Number of travelers, Agreed booking price, and Tour viability result describe this booking.
Where Tour Fields already exist in a Tour Data Object, remove duplicate Case Fields and use the existing structure. Where the Tour Data Object is missing an attribute, add it there. Where no existing Data Object represents the same business entity for the same intended uses, create a proposed Tour Data Object and refine its definition with stakeholders.
Retain generated choices where the name, meaning, and relationship support the outcome. Refine the model where one entity is fragmented across several Fields, Case data and reusable data are difficult to distinguish, a result required by the Case outcome is missing, a relationship does not communicate its role, or the same term carries several meanings.
The model is ready for detailed refinement when stakeholders and the Solution Designer can explain the principal business entities, the data created through Tour Booking, the relationships required by the outcome, where Blueprint represents the business intent clearly, and which questions still require analysis.
Evaluate readiness for detailed refinement
Before refining individual Fields, confirm that the first-pass model answers the following questions:
- Does each proposed entity have a distinct business meaning?
- Does the Case Design require the entity, attribute, relationship, or result?
- Is Case-created data distinguishable from reusable business data?
- Are important relationships or Decision dependencies missing?
- Which assumptions still require business or technical evidence?
Summary
Stakeholders and the Solution Designer establish a shared business view of the data Tour Booking requires, review the starting interpretation generated by Blueprint, and clarify the principal business entities, Case data, relationships, and open questions. These decisions give the team a clear business foundation for refining Fields and structuring related data.
The first-pass model identifies the business entities and relationships Tour Booking needs. The next design decision is more precise: which individual Fields define those concepts, which data belongs to the Case, which data belongs within a parent structure, and which existing records the Case should reference.
Knowledge check
Check your knowledge with the following interaction.
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?