Clarification on Recipient Schema and Relational Schemas in AJO Campaign Orchestration

[Parvesh_Parmar]

Hi everyone,

In the new Adobe Campaign Orchestrations release, we now have the capability to define relational schemas. While going through the documentation, I noticed mentions of a “recipient” schema, and I have some questions regarding how it works:

1. As I understand it, there is no out-of-the-box recipient relational schema in AJO (unlike Adobe Campaign Classic), so any recipient schema needs to be built manually. Is that correct?

2. If we build a recipient schema and additional relational schemas (e.g., loyalty transactions, loyalty membership) and link them to the Profile schema, do we also need to manually populate the data in these schemas for them to work with targeting and identity relationships? Or is there some automatic mechanism (like a view over Profile) that populates these schemas? I belive need to fill maully, no view.

My concern is this: if data is already coming into the Profile Service, and then we also need to load the same data again into a recipient schema (a manually created relational schema), that could lead to duplication and extra maintenance effort.

From what I understand, a relational schema is only really useful in cases where data comes in batch at the profile level (e.g., loyalty membership data). In that case, we would store it in the relational schema, include a customer ID or other unique identity, link it via a namespace to the Profile schema, and then use it as part of targeting in new build audience activity.

This makes sense, but maintaining an extra recipient schema still seems like a challenge.

I’d like to confirm if my understanding is correct, and also hear about the best practices for handling data in these relational schemas in AJO.

Thanks in advance for your help!

[Mayank_Gandhi · Accepted solution]

@Parvesh_Parmar  Your understanding is correct.If the relational schema’s information is already present in Profile, duplication is likely unless integration processes are optimized. Sharing a few best practices:

1. Only create relational schemas for truly relational, multi-record (1:N) domains.
   If data is simple and 1:1 with profile, keep it in the Profile schema.

2. Link with identity namespaces
   Always ensure the relational data can be joined to profiles via a stable ID (e.g., accountId, loyaltyId) and declare appropriate namespaces.

3. Automate data loads
   Use scheduled batch ingestions, connectors, ETL jobs, or Real-Time CDP “source connectors” to minimize manual effort and risk of duplication.

4. Avoid unnecessary duplication
   Only duplicate data in both Profile and relational schemas if both are needed for workflows (e.g., profile-based journeys and relational-targeted segmentation/audiences).

5. Monitor and reconcile

cc @Ivan_Mironchuk