Refine the Case Data Model

Elena’s account distinguishes booking-specific information from reusable information about tours, customers, equipment, and operating conditions. This topic turns that distinction into deliberate Field definitions and relationship choices, so the Blueprint communicates what each value means, where it belongs, and how Tour Booking uses it.

Fields give the Case Data Model its business precision. A clearly defined Field helps stakeholders understand the data, gives Pega Blueprint™ stronger context for AI-generated sample data, allows the Case Design to use the Field consistently, and gives the Solution Builder clearer implementation intent.

For each Field used by the Case journey, a Decision, an integration, or the Case outcome, define:

• its business purpose and a name stakeholders recognize;
• a description that explains what the data represents and why the Case needs it;
• a Field Type that preserves the expected form of the data;
• how the data is established, such as user input, Picklist, calculation, or initialization;
• any recognized options, ranges, formats, or business conditions;
• whether the Field is Primary and therefore part of the key context presented to the user.

Begin with the business purpose, then select the Blueprint options that support it. Tour date and time should communicate more than the presence of a date and time. Its description can explain that the Field represents the requested start of this booking and supports availability and viability Decisions.

Descriptions also help distinguish Fields with similar names. Work Status communicates the operational state of the Case in Pega. Booking status communicates a business state recognized by customers and colleagues. Created date/time and Booking submitted date/time represent different business events.

Field descriptions also give Blueprint context for AI-generated sample data. A generic Field such as Name provides little information about the data expected. A description that identifies the business subject and purpose gives Blueprint a stronger basis for generating relevant examples in Preview.

Define how the Field represents the data

The Field Type communicates the kind of data the Field holds and gives Pega a basis for presenting and validating that data. Select the Type that best preserves the business meaning, such as Integer for Number of travelers, Date for Tour date and time, or Currency for Agreed booking price.

Also establish how the Field receives its data. A user can enter or select the data, the Case may initialize it from information already known, or business logic may calculate it from other Fields. Where the data is calculated, use the Field description to identify the inputs and intended result so the calculation requirement remains visible to stakeholders and the Solution Builder.

Together, the Field purpose, name, description, Type, and source establish what the Field means and how its data is produced. The remaining decision is whether the Field should be Primary. Primary Fields identify the small set of data that gives the user the most useful immediate context for recognizing and understanding the Case or Data Record. For Tour Booking, Selected Tour name, Tour date and time, and Lead Customer Account can provide that context. Select the smallest set that creates a meaningful business summary.

Assure data quality

Data quality does not result from selecting a Field Type alone. The Solution Designer must make the business expectations for the data visible in Blueprint so stakeholders can validate them and the Solution Builder does not need to reconstruct them during Authoring.

Number of travelers shows how several design decisions work together:

Number of travelers shows that data quality depends on more than selecting the correct Field Type. To make data-quality requirements visible in Blueprint, apply the following practices:

• Record validity requirements that always apply in the Field description. 
• For a complex requirement, include the intent in the Field description and create a Business Rule to define the complete logic, especially where the check uses several Fields or needs to be reused. 
• Use the relevant Step settings and Step Note to preserve when the Rule applies, the guidance shown to the user, and what the Case should do when the data does not satisfy the applicable business Rule.

Once the individual Fields are defined, evaluate which Fields belong together and whether the data describes a reusable business entity or belongs within a parent.

Evaluate the Field definition

Ask these questions to evaluate each Field definition:

• Does the Field name identify the business concept clearly?
• Does the description explain what the value represents and why the Case needs it?
• Does the Field Type preserve the expected form of the value?
• Is the source of the value clear?
• Are generally applicable and contextual validity requirements distinguished?
• Is Primary selected only when the Field adds useful immediate context?

Related Fields need a structure that reflects what the data describes. Decide whether the Fields describe a reusable business entity or data that belongs within a parent Case, Data Object, or Embedded Data structure.

A Data Object defines a reusable business entity and can support its own Data Records. Embedded Data organizes related Fields within a parent Case, Data Object, or Embedded Data structure. Data Reference connects the parent to an existing Data Record.

Data Objects

A Data Object brings together the related Fields that describe a business entity and can support Data Records that exist beyond a single Case.

For example, the Tour Data Object may define Tour name, location, duration, Standard capacity, and operating requirements. A specific Tour is represented by a Tour Data Record containing data in those Fields.

Embedded Data

Embedded Data adds meaningful structure within its parent by grouping related Fields, keeping the Data Model organized, and ensuring that the same structured definition is used consistently wherever the parent is used. It is used to capture and hold data as part of that parent rather than to connect to an existing Data Record.

When Embedded Data belongs directly to Tour Booking, the captured data forms part of the Case. When Embedded Data belongs inside a Data Object, it organizes one aspect of that business entity, and the captured data forms part of each Data Record.

For example, Equipment Assignments in Tour Booking may group Equipment name, quantity, issue condition, booking notes, and return status. An Operating Window inside the Tour Data Object may group opening time, closing time, applicable days, and seasonal period.

Data Reference

A reusable Data Object may represent a business entity that exists beyond the Case Type and support Data Records used by different parts of the application. When the Case needs to use an existing Data Record, Data Reference creates that relationship.

For example, Tour is a reusable business entity beyond Tour Booking. Selected Tour connects Tour Booking to one existing Tour Data Record, allowing the Case to use the Tour data without recreating the Tour Fields on every booking.

Choosing between Data Objects, Embedded Data, and Data References depends on whether the data represents an independent reusable entity, an owned internal structure, or an existing record pointer.

The following figure shows how Data Objects, Embedded Data, and Data References represent different ways of structuring and relating data within a Case:

Other relationships

Blueprint also provides specific Field Types for relationships to Pega users and other Cases.

Use User Reference when Tour Booking needs to identify a particular Pega user in a business role. The Persona defines the participant group with shared responsibilities; User Reference identifies the individual who fulfills a specific role for this Case. For example, Assigned Tour Guide may identify the user responsible for guiding the booked Tour.

Use Case Reference when Tour Booking needs to connect to another Case instance. For example, Related Vendor Management Case may connect Tour Booking to separate work that retains its own purpose, data, progress, and outcome.

For each relationship, establish:

• the business role it serves;
• whether it represents one occurrence or a list;
• whether a user or business logic establishes it.

Name the Field for its role in Tour Booking, such as Assigned Tour Guide or Related Vendor Management Case.

Select the relationship that matches the business need

Use the following table to select the relationship type that matches what Tour Booking needs to do:

The Field and structure definitions establish what the data means. Step configuration establishes how the data supports a particular interaction. The same Field may be editable during information capture, read-only during review, visible only when a condition applies, or required when the Case reaches the point where the data is needed.

For each Field used in an Assignment Step, define whether it is visible, required, and read-only. Where Blueprint supports a condition, use the Step Field settings. Where the intended UI control, validation, or user guidance cannot be represented, record it in the relevant Step Note.

For Number of travelers, the Field definition explains what the data means. At the booking Step, Blueprint establishes that the Field is visible, required, and editable. A capacity condition determines whether Number of travelers exceeds the Standard capacity of Selected Tour. A Step Note preserves the required guidance where Blueprint cannot express the complete behavior.

Return to View Relationships and review the Case Data Model as one connected design. Confirm that stakeholders can identify:

• Individual Case Fields
• Embedded Data and the parent that gives it context
• Existing Data Records used through Data Reference
• Pega users and related Cases
• The business role of each relationship
• One-record and list choices
• Dependencies required by the selected outcome

Follow the principal relationships into their Data Objects. Confirm that each Data Object represents one coherent business entity and remains recognizable wherever it is used. Before defining another representation, investigate whether an approved Data Object already provides the required business meaning, Field meanings, ownership, source responsibility, and intended use. Reuse it where these align; represent meaningful differences separately in Blueprint.

Blueprint now presents a coherent Pega Data Model for Tour Booking. Fields carry clear business meaning and data-quality intent. Related data is placed within the Case, structured as Embedded Data, or connected through the appropriate reference. Together, these decisions preserve where data belongs, how Tour Booking uses it, and the role each relationship serves throughout the Case journey.

The refined Case Data Model now explains what the data means and where it belongs. The next question is where reusable records and externally supplied values come from, what Tour Booking exchanges across the application boundary, and when that information is fit for use.

Check your knowledge with the following interaction.