Skip to main content

Data and Integration Design review challenges

The AI-generated content in Pega Blueprint™ provides a practical starting point for Data and Integration Design. Experienced Solution Designers review the complete design to understand how significant data is represented, sourced, exchanged, changed, and used across the solution.

This connected review reveals decisions whose effects extend beyond an individual Field, Data Object, source, or interaction. By clarifying these decisions in Blueprint, the Solution Designer strengthens business understanding and gives Authoring a more reliable basis for delivery.

Tip: Review the complete Data and Integration Design before refining an individual Field, Data Object, source, or interaction. Understand the dependencies the design currently represents, then focus on the decisions with the greatest effect on business meaning and delivery.

Are the Data and Integration Design decisions clear enough to progress?

Working with business stakeholders evolves the Tour Booking Data and Integration Design from its AI-generated starting point into a more complete representation of the business need. Individual Data Objects, relationships, sources, and interactions may each appear reasonable when reviewed separately. Their combined effect becomes clear when the team follows the data across the solution: a relationship choice influences ownership and access, a source decision influences currency and persistence, and an external interaction influences the data required by the Case and the response the Workflow must support.

Before delivery progresses, review the design as a whole to identify decisions that still require business evidence or clearer business intent in Blueprint. Use the following focus areas to review the design:

Review focus area

Validation question

Data placement and relationship

Does the data belong to Tour Booking, an Embedded Data structure, or an existing Data Record?

Outbound data exchange

Are the data Tour Booking supplies and the data the Resource returns clearly defined?

Data persistence

Are the accepted values, system of record, persistence point, and required save result defined?

Inbound event

Does the inbound-event definition establish what each event causes, how existing work is identified, which system sends it, which variants matter, and what response is expected?


These review focus areas help the Solution Designer identify the decision beneath each visible design issue and trace its effect across connected choices. The following examples show how clarifying the business purpose leads to a focused refinement that carries one consistent intent through the design.


Challenge 1: Does the data placement express ownership and reuse clearly?

Starting design

The AI-generated design represents Equipment Assignments through separate Fields, leaving their ownership and structure open. It remains unclear whether they describe booking-specific assignment data or identify reusable Equipment Data Records. This decision affects relationship type, multiplicity, Views, runtime access, and the level at which existing value can be reused.

Tip: Confirm whether Tour Booking requires a repeatable, parent-owned Equipment Assignment structure or a relationship to existing Equipment Data Records. Confirm whether the business requires one assignment or a list, and distinguish the reusable Equipment information from the assignment data whose meaning belongs to the individual booking.

Refine the relationship around ownership and purpose

Represent Equipment Assignments as a list of Embedded Data owned by Tour Booking, with their relationship role and multiplicity defined in the Case Data Model. Retain a connection to reusable Equipment Data Records where the assignment needs to identify inventory.

This allows the established Equipment Data Object to provide shared inventory information while quantities, sizes, issue status, and other booking-specific values remain within Equipment Assignments.

Note: Resolving ownership first gives the connected design one consistent interpretation. It also distinguishes reusable Equipment data from the assignment data whose business meaning and ownership arise from the individual booking.

Design review tips

  • Ownership: Does the data belong to Tour Booking or to an established Data Record?
  • Identity: Is reusable Equipment information distinguished from booking-specific assignment data?
  • Multiplicity: Does the relationship represent one occurrence or a list?
  • Reuse: Is established information referenced rather than recreated?


Challenge 2: Does the outbound exchange support the Decision need?

Starting design

The AI-generated design identifies Operating Conditions as an external capability used by Determine Tour Viability. The dependency is visible, while the exchange remains open: Tour Booking has yet to define the location and scheduled time it supplies or the weather, tide level, and observation time it expects in return.

Returned data can be technically valid while representing another location, time, unit, or level of detail. These differences affect whether Determine Tour Viability evaluates the conditions relevant to the scheduled Tour.

Tip: Confirm what Tour Booking supplies, what the Resource returns, whether both representations retain the same meaning, whether the values represent the selected Tour location and scheduled time, use the required units, and provide the detail required by Determine Tour Viability, and which known trust assumption affects the dependency.

Refine the exchange around the Decision need

Define the Resource and Field information around the Decision it supports. Record the Tour location and scheduled time supplied by Tour Booking, the operating-condition data returned, and any difference in meaning, representation, or units that Authoring must resolve. Keep known source and trust assumptions visible.

Note: A clear outbound exchange gives the delivery team a stable basis for scoping and completing the integration. It establishes the business intent needed to refine request and response mappings, runtime access, caching, refresh, authentication, testing, and error handling. This reduces rediscovery during Authoring and keeps the integration aligned with the Decision and Case outcome.

Design review tips

  • Purpose: Is the business result of the exchange clear?
  • Inputs and outputs: Are supplied and returned values defined?
  • Meaning: Are codes, units, formats, and time context aligned?
  • Fitness: Will the returned values be current and trusted enough for the Decision?


Challenge 3: Is the accepted change and persistence responsibility clear?

Starting design

The Tour Booking design includes optional work for updating permitted customer information. The Case can capture proposed values, while the connected design remains unclear about when those values become an accepted Customer Account change, which system must retain them, and how the save result affects the Case.

A booking-specific contact change may remain only within Tour Booking, while an accepted account change may update the continuing Customer Account. The distinction affects persistence, mapping, save behavior, and subsequent Case progression.

Tip: Confirm which values are accepted, how they are established, which system owns the Data Record, when the accepted values must be saved to that system, and how Tour Booking uses the save result.

Refine persistence around the accepted change

Record the accepted Customer Account values, owning system, persistence point, required save result, and the Case progression that depends on that result. Keep the business response clear for a save that succeeds, remains outstanding, or is unsuccessful.

Note: A clear persistence requirement connects the optional work with the responsibility to update the continuing Customer Account. It gives the delivery team a stable basis for refining mapping, save planning, transaction behavior, failure response, and Case progression while keeping Tour Booking and the owning system aligned.

Design review tips

  • Acceptance: Which proposed values become continuing Customer Account data?
  • Ownership: Which system must retain the accepted values?
  • Timing: When must the save occur?
  • Result: How does Tour Booking respond to success, delay, or failure?


Challenge 4: Does each inbound event cause the intended Case effect?

Starting design

The partner booking event identifies Tour Booking as the affected Case Type. The current definition groups several possible variants while the design has yet to establish which create a new Case, which update an existing Case, which business data identifies the affected Case, which sending system is expected, or which known trust assumption applies. The expected acknowledgment or business response also requires definition.

Explicit matching and event intent help the same partner interaction create or update the intended work and return a response that communicates the business result.

Tip: Confirm what each event variant causes, how existing work is identified, which sending system initiates the event, which known trust assumption applies, which variations change the Case effect, and which response the sending system expects.

In this scenario, the event variants have distinct Create or Update effects. Record the event purpose, Case effect, matching data, sending system, significant variants, known trust assumption, and expected response.

This allows stakeholders to validate the event outcome and gives Authoring clear intent for identifying the affected Case and returning the expected response.

Review the connected design

Bring the findings from the four focus areas together and review their combined effect across the connected design. Walk through representative business situations with stakeholders and follow the data from its meaning and ownership through to its use, exchange, change, or retention.

  • Meaning and integrity: Can stakeholders interpret the data consistently? Are its Type, permitted values, required point, units, time context, and business conditions defined for the Step, Decision, or outcome that uses it?
  • Placement, ownership, and reuse: Does the data belong to the Case, an Embedded Data structure, an existing Data Record, or a related Case? Does established value carry the same business meaning, identity, ownership, and source responsibility? Which data remains specific to Tour Booking?
  • Establishment and use: Is it clear how each material value is established, when it changes, and where the Case uses it? For initialized or calculated values, are the source, inputs, timing, and recalculation need defined?
  • Source and exchange: Is the source understood? Is Tour Booking retrieving existing data, creating or updating a Data Record, requesting an external operation, or receiving an event? Are the data supplied and returned, differences in meaning or representation, currency, and known trust assumptions clear?
  • Change and continuity: Are accepted changes, persistence, Case effect, expected responses, and outcome evidence defined? Is each requirement recorded once, close to the decision it explains?

Apply these review areas to representative situations across the design. For Equipment Assignments, distinguish the reusable Equipment Data Record from the assignment data whose meaning and ownership belong to the individual booking. Continue by tracing what Operating Conditions Tour Booking supplies and receives, how an accepted Customer Account change progresses to its owning system, and how each partner booking event affects a Case.

Tip: Walk through representative business situations and follow the data across the connected design. Identify where established value carries the required business meaning and responsibility, where purposeful variation belongs, and which decisions require further business evidence, focused Blueprint refinement, or progression through Authoring.
Note: These decisions determine whether the application represents business data consistently as it is captured, referenced, exchanged, changed, and received. Reviewing them together with stakeholders exposes conflicts that remain hidden when each Blueprint area is considered separately. The refined design gives stakeholders a reliable business explanation and gives Authoring clear intent grounded in that explanation.

Design review tips

  • Effect: Does each variant create or update the correct Case?
  • Matching: Is the information used to identify existing work clear?
  • Trust: Is the expected sending system and trust assumption visible?
  • Response: Does the sender receive the required business result?

Which refinements create the greatest delivery confidence?

The connected review may reveal several worthwhile refinements, but their consequences differ. Some resolve foundational decisions that shape the wider design; others improve a local Field, Resource, description, or Note.

Data and Integration Design decisions form dependencies. Ownership influences source and persistence. Business meaning influences Field definitions and mappings. Interaction purpose influences exchanged data and expected results. Refining a dependent detail before its foundation is settled can create work that must be revisited.

Prioritize the unresolved decision that influences the greatest number of connected choices. For example, confirming the Customer Account system of record establishes the basis for source intent, accepted updates, persistence, mapping, and integration scope. A clearer Field description adds useful precision, but its effect remains local. Resolve the foundational decision first, then refine the supporting detail.

Prioritize across the connected design

Begin with foundation and consequence. Use dependencies to understand the reach of the decision. Confirm whether current evidence supports refinement. Preserve the rationale required for continuity, then select the change that creates the greatest value across the connected design.

  • Foundation: Which unresolved decision informs the greatest number of later choices?
  • Consequence: Which issue most affects the Case outcome, delivery scope, or stakeholder understanding?
  • Dependencies: Which Blueprint and Authoring decisions rely on this information?
  • Evidence: Which finding can be resolved from current business evidence?
  • Continuity: Which rationale must remain recorded for Authoring?
  • Value: Which focused refinement creates the greatest improvement across dependent decisions?

Prioritization remains iterative. Greater clarity in one area may change the significance of another refinement. Retain design elements that already serve their purpose and revisit the sequence as new business evidence develops.

Note: Purposeful prioritization directs stakeholder attention to the decisions with the greatest effect on the connected design. Resolving foundational questions first protects business meaning across the dependent choices, creates a more stable basis for Authoring, and makes each later refinement more reliable.

Summary

A refined Data and Integration Design is coherent, purposeful, reusable where business meaning and responsibility align, and clear about the decisions that carry into Authoring. Experienced Solution Designers develop these qualities by reviewing the connected design, explaining the consequences of open decisions, preserving the supporting business evidence, and prioritizing the changes with the greatest effect on delivery confidence.

The review remains iterative. Greater clarity about one dependency may change an earlier decision about placement, source, persistence, interaction, or reuse. The examples in this topic illustrate transferable thinking patterns rather than an exhaustive set of techniques.

This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Yes
No

Want to help us improve this content?
Suggest an edit

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice