Define a many-to-one relationship between two schemas in Real-Time Customer Data Platform B2B Edition relationship-b2b
Adobe Real-Time Customer Data Platform B2B Edition provides several Experience Data Model (XDM) classes that capture fundamental B2B data entities, including accounts, opportunities, campaigns, and more. By building schemas based on these classes and enabling them for use in Real-Time Customer Profile, you can merge data from disparate sources into a unified representation called a union schema.
However, union schemas can only contain fields captured by schemas that share the same class. This is where schema relationships come in. By implementing relationships in your B2B schemas, you can describe how these business entities relate to each other and can include attributes from multiple classes in downstream segmentation use cases.
The following diagram provides an example of how the different B2B classes can relate to each other in a basic implementation:
This tutorial covers the steps to define a many-to-one relationship between two schemas in Real-Time CDP B2B Edition.
Getting started
This tutorial requires a working understanding of XDM System and the Schema Editor in the Experience Platform UI. Before beginning this tutorial, please review the following documentation:
- XDM System in Experience Platform: An overview of XDM and its implementation in Experience Platform.
- Basics of schema composition: An introduction of the building blocks of XDM schemas.
- Create a schema using the Schema Editor: A tutorial covering the basics of how to build and edit schemas in the UI.
Define a source and reference schema
It is expected that you have already created the two schemas that will be defined in the relationship. For demonstration purposes, this tutorial creates a relationship between business opportunities (defined in an “Opportunities” schema) and their associated business account (defined in an “Accounts” schema).
Schema relationships are represented by a dedicated field within a source schema that references the primary identity field of a reference schema. In the steps that follow, “Opportunities” serves as the source schema, while “Accounts” acts as the reference schema.
Understanding identities in B2B relationships
In order to establish a relationship, the reference schema must have a defined primary identity. When setting a primary identity for a B2B entity, keep in mind that string-based entity IDs may overlap if you are collecting them across different systems or locations, which could lead to data conflicts in Platform.
To account for this, all standard B2B classes contain “key” fields that conform to the B2B Source data type. This data type provides fields for a string identifier for the B2B entity along with other contextual information about the identifier’s source. One of these fields, sourceKey
, concatenates the values of the other fields in the data type to produce a wholly unique identifier for the entity. This field should always be used as the primary identity for B2B entity schemas.
For reference purposes, the following sections describe the structure of each schema used in this tutorial before a relationship has been defined. Take note of where the primary identities have been defined in the schema structure and the custom namespaces they use.
Opportunities schema
The source schema “Opportunities” is based on the XDM Business Opportunity class. One of the fields provided by the class, opportunityKey
, serves as the identifier for the schema. Specifically, the sourceKey
field under the opportunityKey
object is set as the schema’s primary identity under a custom namespace called B2B Opportunity.
As seen under Schema Properties, this schema has been enabled for use in Real-Time Customer Profile.
Accounts schema
The reference schema “Accounts” is based on the XDM Account class. The root-level accountKey
field contains the sourceKey
that acts as its primary identity under a custom namespace called B2B Account. This schema has also been enabled for use in Profile.
Define a relationship field for the source schema relationship-field
In order to define a relationship between two schemas, the source schema must have a dedicated field that indicates the primary identity of the reference schema. Standard B2B classes include dedicated source key fields for commonly related business entities. For example, the XDM Business Opportunity class contains source key fields for a related account (accountKey
) and a related campaign (campaignKey
). However, you can also add other B2B Source fields to the schema by using custom field groups if you require more than the default components.
To set a relationship field, select the arrow icon (
) next to the field in question within the canvas. In the case of the Opportunities schema, this is the accountKey.sourceKey
field since the goal is to establish a many-to-one relationship with an account.
A dialog appears that allows you to specify the details about the relationship. The relationship type is automatically set to Many-to-one.
Under Reference Schema, use the search bar to find the name of the reference schema. When you highlight the reference schema’s name, the Reference Identity Namespace field automatically updates to the namespace of the schema’s primary identity.
Under Relationship Name From Current Schema and Relationship Name From Reference Schema, provide friendly names for the relationship in the context of the source and reference schemas, respectively. When finished, select Save to apply the changes and save the schema.
The canvas reappears, with the relationship field now marked with the friendly name you provided earlier. The relationship name is also listed under the left rail for easy reference.
If you view the structure of the reference schema, the relationship marker appears next to the schema’s primary identity field and in the left rail.
Next steps
By following this tutorial, you have successfully created a many-to-one relationship between two schemas using the Schema Editor. Once data has been ingested using datasets based on these schemas and that data has been activated in the Profile data store, you can use attributes from both schemas for multi-class segmentation use cases.