Establish data source and delivery intent

Organizations often already rely on systems that manage customer, product, payment, location, or operational data. A new Pega application needs to use those established capabilities while making the resulting dependency visible.

Begin with the reusable Data Objects represented in Blueprint and the points where Tour Booking needs their data. Blueprint may already have associated a Data Object with an external system or generated candidate Integration Systems and Resources.

Review the generated design against the Case outcome:

• Does each external system represent a capability Tour Booking needs?
• Does each Resource represent business data or a service required by the Case Design?
• Does an existing interface or service provide the access Tour Booking requires?
• Are required systems, Resources, or access capabilities missing?
• Does a generated dependency sit outside the selected outcome or release?
• Does an unresolved source or access dependency need to remain visible while the team confirms how the data will be provided?

Retain generated choices that support the outcome. Refine their business meaning and add missing systems or Resources where the Case Design reveals an unmet dependency.

For Tour Booking, Tour records can be managed locally in Pega. Customer Account records can come from an established customer platform. Determine Tour Viability may depend on weather or tide data supplied by an external provider.

The source choice reveals which parts of the Case Data Model create delivery dependencies beyond the application.

Recognize the delivery consequence

An external source is more than a location for data. The Case outcome now depends on another capability being available and fit for the intended use.

That dependency may introduce API readiness, authentication, mapping, testing, error handling, and release-planning work. Use Data & Integrations to show whether a Data Object is sourced locally, associated with a known Integration System and Resource, or still awaiting source confirmation.

Once an external dependency is confirmed, increase its fidelity in Blueprint.

Begin with what Blueprint has already generated. Review the Integration System name, the description of what the system provides, its Resources and Fields, and any operations or settings already available.

A useful Integration System tells the delivery team:

• what the external system contributes to the business outcome;
• which Resources Tour Booking uses;
• what each Resource represents in business language;
• where the Case Design depends on the Resource;
• what data or result the Case expects;
• which assumptions still require technical confirmation.

State the direction and intended business effect of the exchange

Clarify whether Tour Booking retrieves existing data, submits a new Data Record, updates an existing record, requests an external operation, receives a business result, or responds to an inbound event. A relationship to a Data Record does not establish whether the application reads, creates, updates, or saves that record.

Preserve semantic alignment across the boundary

An external integration can exchange data successfully while representing its meaning differently from the Pega Data Model. For each exchanged value, confirm whether the external source and the Pega Data Model use the same meaning, Type, units, format, and level of detail. Where they differ, record how Tour Booking should interpret or convert the value.

For Operating Conditions, compare the external location identifier with Tour location, the tide value and unit with the value used by Determine Tour Viability, and the observation time with the scheduled Tour time. These comparisons establish how the external data must be understood before the Case can use it reliably.

Where an API or schema definition is available, Blueprint can use the imported specification to generate integration structures, operations, mappings, and Data Model content. Where no definition is available, begin the Integration System manually and refine it as technical information becomes available.

Confirm that the integration capability is available

A defined source does not always mean that Tour Booking can access the required data. Confirm whether an appropriate interface or service exists and whether it supports the exchange required by the Case Design.

The Solution Builder and architecture roles progressively validate and complete endpoint URLs, operations, authentication, request and response structures, mappings, and technical behavior. The Solution Designer preserves the purpose, expected exchange, point of use, and unresolved dependency so that this technical refinement begins from clear design intent.

Preserve the design intent in the closest Blueprint location

An integration depends on several connected decisions: what the reusable data represents, what the external capability provides, which Resource supports the interaction, what each exchanged value means, and when the Case uses it. Preserve each decision in the Blueprint location that gives it the clearest context.

The following figure shows where each integration design decision should be recorded in Blueprint to preserve its intent in the clearest context:

Some dependencies begin outside the application. An inbound API call, file, email, message, or AI request may create a new Case or update an existing Case. Use the Inbound Events panel in Blueprint to identify the event category, explain its business purpose, and select the Case Types it may create or update. This makes externally initiated work visible before the runtime design is completed.

A single event category may represent several APIs, inboxes, file layouts, messages, or Channels. These may serve different purposes, affect different Case Types, or use different data to identify existing Cases. Capture these meaningful variations in the event description so the delivery team can understand and estimate the complete dependency.

For Tour Booking, U+ Travel may receive booking requests and booking changes through partner APIs, approved digital Channels, email addresses, and operating files. Some events create a Tour Booking Case. Others update an existing booking when an accepted booking identifier is supplied. Vendor-related events may create or update Vendor Management work.

For each inbound event, identify:

• Where the event originates
• The business purpose it serves
• Whether it creates a new Case or updates an existing Case
• Which Case Types it affects
• The data used to identify an existing Case
• The expected response
• How unsupported or unmatched events should be handled

Where one Blueprint entry represents several event variants, use the description to preserve the differences that the structured Fields cannot express. The Solution Builder can then refine routing, Case matching, security, validation, and exception behavior during Authoring.

The Blueprint Import Module can create a technical starting point for supported inbound-event types. The Solution Builder reconciles the generated artifacts with the event variants, Case mappings, and delivery assumptions recorded in Blueprint.

External data can change while a Case progresses. The source must provide data that represents the time, event, or business condition required by the work or Decision that uses it.

For each item of time-sensitive external data, the design states the requirement. The refresh mechanism is settled during Authoring.

The following figure shows how the Solution Designer defines when sourced data is fit for use while the Solution Builder determines the refresh and retrieval design during Authoring:

Access consideration

Source and access are separate decisions.

Persona access describes what application users may do with Cases and Data Objects. Integration trust describes which external systems may call the application and how Pega identifies itself when calling them.

Identify any access assumption that materially affects the external dependency. Develop the complete access model through Persona and Channel Design and refine technical enforcement during Authoring.

Review readiness

The Blueprint is ready to progress when stakeholders and the delivery team can explain:

• which Data Records are local, external, or awaiting source confirmation;
• which external systems, Resources, and inbound events affect the selected outcome;
• what crosses the application boundary, how the Case uses it, and when sourced data is fit for use;
• which integration capabilities, access dependencies, and delivery assumptions remain unresolved;
• which remaining questions concern Authoring choices rather than unresolved design intent.

Blueprint now makes Tour Booking’s external dependencies clear enough to evaluate and estimate. Stakeholders and the delivery team can identify where Data Records are managed, what crosses the application boundary, how the Case uses it, when sourced data is fit for use, and which delivery dependencies remain unresolved.

In Pega Infinity™, these validated decisions become working data and integration constructs. The next topic examines how those constructs preserve the design intent and where the Solution Builder completes the Authoring detail.

Check your knowledge with the following interaction.