If you are using Real-time Customer Data Platform B2B Edition, see the guide on creating B2B relationships instead.
The ability to understand the relationships between your customers and their interactions with your brand across various channels is an important part of Adobe Experience Platform. Defining these relationships within the structure of your Experience Data Model (XDM) schemas allows you to gain complex insights into your customer data.
While schema relationships can be inferred through the use of the union schema and Real-time Customer Profile, this only applies to schemas that share the same class. To establish a relationship between two schemas belonging to different classes, a dedicated relationship field must be added to a source schema, which references the identity of a destination schema.
This document provides a tutorial for defining a relationship between two schemas using the Schema Editor in the Experience Platform user interface. For steps on defining schema relationships using the API, see the tutorial on defining a relationship using the Schema Registry API.
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:
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 members of an organization’s loyalty program (defined in a “Loyalty Members” schema) and their favorite hotel (defined in a “Hotels” schema).
In order to establish a relationship, both schemas must have defined primary identities and be enabled for Real-time Customer Profile. See the section on enabling a schema for use in Profile in the schema creation tutorial if you require guidance on how to configure your schemas accordingly.
Schema relationships are represented by a dedicated field within a source schema that refers to another field within a destination schema. In the steps that follow, “Loyalty Members” will be the source schema, while “Hotels” will act as the destination schema.
For reference purposes, the following sections describe the structure of each schema used in this tutorial before a relationship has been defined.
The source schema “Loyalty Members” is based on the XDM Individual Profile class, and is the schema that was constructed in the tutorial for creating a schema in the UI. It includes a
loyalty object under its
_tenantId namespace, which includes several loyalty-specific fields. One of these fields,
loyaltyId, serves as the primary identity for the schema under the Email namespace. As seen under Schema Properties, this schema has been enabled for use in Real-time Customer Profile.
The destination schema “Hotels” is based on a custom “Hotels” class, and contains fields that describe a hotel.
In order to participate in a relationship, the destination schema must have a primary identity. In this example, the
hotelId field is used as the primary identity, using a custom “Hotel ID” identity namespace.
To learn how to create custom identity namespaces, refer to the Identity Service documentation.
Once the primary identity has been set, the destination schema must then be enabled for Real-time Customer Profile.
This step is only required if your source schema does not have a dedicated string-type field to be used as a reference to the destination schema. If this field is already defined in your source schema, skip to the next step of defining a relationship field.
In order to define a relationship between two schemas, the source schema must have a dedicated field to be used as a reference to the destination schema. You can add this field to the source schema by creating a new schema field group.
Start by selecting Add in the Field groups section.
The Add field group dialog appears. From here, select Create new field group. In the text fields that appear, enter a display name and description for the new field group. Select Add field groups when finished.
The canvas reappears with “Favorite Hotel” appearing in the Field groups section. Select the field group name, then select Add field next to the root-level
Loyalty Members field.
A new field appears in the canvas under the
_tenantId namespace. Under Field properties, provide a field name and display name for the field, and set its type to “String”.
When finished, select Apply.
favoriteHotel field appears in the canvas. Select Save to finalize your changes to the schema.
Once your source schema has a dedicated reference field defined, you can designate it as a relationship field.
favoriteHotel field in the canvas, then scroll down under Field properties until the Relationship checkbox appears. Select the checkbox to reveal the required parameters for configuring a relationship field.
Select the dropdown for Reference schema and select the destination schema for the relationship (“Hotels” in this example). If the destination schema is enabled for Profile, the Reference identity namespace field is automatically set to the namespace of the destination schema’s primary identity. If the schema does not have a primary identity defined, you must manually select the namespace that you plan to use from the dropdown menu. Select Apply when finished.
favoriteHotel field is now highlighted as a relationship in the canvas, displaying the name and reference identity namespace of the destination schema. Select Save to save your changes and complete the workflow.
By following this tutorial, you have successfully created a one-to-one relationship between two schemas using the Schema Editor. For steps on how to define relationships using the API, see the tutorial on defining a relationship using the Schema Registry API.