Best Practices for Capturing Data and Integrations in Pega Blueprint from a field challenge

Blueprint and App Design
1

Context

One LBA from our NA field team is currently working on a Blueprint for a Partner Onboarding process and has encountered a few scenarios that raise questions about the best way to represent data requirements in Blueprint. Specifically:

  • Scenario 1: At the beginning of the process, the partner data System of Record (SOR) is queried to check if the partner already exists. If found, the data is retrieved and propagated to the case. At the end of the process, Pega sends the new or updated partner data back to the same SOR.
    Question: Should we capture the SOR only once in Blueprint? How should we best represent multiple calls to a single system?

  • Scenario 2: In some cases, partner data is stored in two SORs. A second SOR is queried only when a specific party ID is returned by the first SOR—typically when the partner is a subsidiary of a larger dealer organization.
    Question: Should we create separate data objects for the parent Dealer and the Partner subsidiary? Do we need to capture both SORs if the call is orchestrated by middleware?

Best Practices for Capturing Data and Integrations from the field challenge above### Scenario 1: Single SOR with Multiple Calls

Recommendation:

  • Model the partner SOR as a single external data object.
  • Even if it’s called at both the start and end of the process, avoid duplicating it in the Blueprint.
  • Use Automation Step Types to represent each interaction via a Data Page.
  • Focus on the data lifecycle rather than individual API calls—this keeps the Blueprint clean and implementation-friendly.

Scenario 2: Two SORs with Middleware Orchestration

Recommendation:

  • Create separate data objects for the parent Dealer and the Partner subsidiary. This provides clarity and aligns with how the data is structured.
  • Even if middleware handles the orchestration, capture both SORs in the Blueprint for full visibility and traceability.

To represent this orchestration clearly:

  • Use a query property when retrieving data from an external SOR (e.g., the Dealer) based on a value returned from another (e.g., a party ID from the Partner SOR). This is read-only, uses a Data Page, and allows parameterized fetching without persisting data in the case.
  • Use a data reference to establish a relationship between the Partner and Dealer data objects. This enables data sharing between entities and supports modeling dependencies in your data structure.

:blue_book: Also Refer to Data modeling

2

@PauloToninthanks for sharing and great to see how you solved these scenarios! For scenario 2 you have created 2 data types, did I understand this correctly? What name did you give them?

3

@schos1​​​​​ yes, you understood it correctly. In Scenario 2, I created two separate data types:

  1. Dealer – representing the parent entity.
  2. Partner – representing the subsidiary or child entity.

This separation reflects the fact that the data originates from two distinct Systems of Record (SORs). Even though middleware handles the orchestration, modeling both entities explicitly in Blueprint ensures:

  • Traceability of data origins.
  • Clarity in how the Partner relates to the Dealer.
  • Flexibility for future changes (e.g., if orchestration logic evolves or one SOR is replaced).

Additionally, creating separate data types also helps any given estimator tools on generating more precise effort and complexity estimates. When data objects are clearly defined and decoupled, estimator tools can better assess:

  • The number of integrations involved.
  • The complexity of data relationships.
  • The reuse potential across case types.