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.

📘 Also Refer to Data modeling