The Adobe Experience Platform user interface allows you to create and manage Experience Data Model (XDM) schemas in an interactive visual canvas called the Schema Editor. This tutorial covers how to create a schema using the Schema Editor.
For demonstration purposes, the steps in this tutorial involve creating an example schema that describes members of a customer loyalty program. While you can use these steps to create a different schema for your own purposes, it is recommended that you first follow along with creating the example schema to learn the capabilities of the Schema Editor.
If you are ingesting CSV data into Platform, you can map that data to an XDM schema created by AI-generated recommendations (currently in beta) without having to manually create the schema yourself.
If you prefer to compose a schema using the Schema Registry API, start by reading the Schema Registry developer guide before attempting the tutorial on creating a schema using the API.
This tutorial requires a working understanding of the various aspects of Adobe Experience Platform involved in schema creation. Before beginning this tutorial, please review the documentation for the following concepts:
The Schemas workspace in the Platform UI provides a visualization of the Schema Library, allowing you to view manage the schemas available for your organization. The workspace also includes the Schema Editor, the canvas on which you can compose a schema throughout this tutorial.
After logging into Experience Platform, select Schemas in the left navigation to open the Schemas workspace. The Browse tab displays a list of schemas (a representation of the Schema Library) for you to view and customize. The list includes the name, type, class, and behavior (record or time-series) on which the schema is based, as well as the date and time the schema was last modified.
See the guide on exploring existing XDM resources in the UI for more information.
To begin composing a schema, select Create schema in the top-right corner of the Schemas workspace.
The Create a schema dialog appears. In this dialog, you can choose to either manually create a schema by adding fields and field groups, or you can upload a CSV file and use ML algorithms to generate a schema. Select a schema creation workflow from the dialog.
To learn how you can use a ML algorithm to recommend a schema structure based on an uploaded file, see the machine learning-assisted schema creation guide. This UI guide focusses on the manual creation workflow.
The Create schema workflow appears. Next, choose a base class for the schema. You can choose between the core classes of XDM Individual Profile and XDM ExperienceEvent, or Other if these classes do not suit your purposes. The Other classes option allows you to either create a new class or choose from other pre-existing classes.
See the XDM individual profile and XDM ExperienceEvent documentation for more information on these classes. For the purposes of this tutorial, select XDM Individual Profile followed by Next.
After you have selected a class, the Name and review section appears. In this section, you provide a name and description to identify your schema. There are several important considerations to make when deciding on a name for your schema:
This tutorial composes a schema to ingest data related to the members of a loyalty program, and therefore the schema is named “Loyalty Members”.
The schema’s base structure (provided by the class) is shown in the canvas for you to review and verify your selected class and schema structure.
Enter a human-friendly Schema display name in the text field. Next, enter a suitable description to help identify your schema. When you have reviewed your schema structure and are happy with your settings, select Finish to create your schema.
The Schema Editor appears. This is the canvas upon which you will compose your schema. The self-titled schema is automatically created in the Structure section of the canvas when you arrive in the editor, along with the standard fields included in the base class that you selected. The assigned class for the schema is also listed under Class in Composition section.
You can update the display name and optional description for the schema from the Schema properties sidebar. Once a new name is entered, the canvas automatically updates to reflect the new name of the schema.
You can change the class of a schema at any point during the initial composition process before the schema has been saved, but this should be done with extreme caution. Field groups are only compatible with certain classes, and therefore changing the class will reset the canvas and any fields you have added.
You can now begin to add fields to your schema by adding field groups. A field group is a group of one or more fields that are often used together to describe a particular concept. This tutorial uses field groups to describe the members of the loyalty program and capture key information such as name, birthday, phone number, address, and more.
To add a field group, select Add in the Field groups sub-section.
A new dialog appears, displaying a list of available field groups. Each field group is only intended for use with a specific class, therefore the dialog only lists field groups that are compatible with the class you selected (in this case, the XDM Individual Profile class). If you are using a standard XDM class, the list of field groups will be intelligently sorted based on usage popularity.
You can select one of the filters in the left rail to narrow down the list of standard field groups to specific industries like retail, financial services, and healthcare.
Selecting a field group from the list causes it to appear in the right rail. You can select multiple field groups if desired, adding each one to the list in the right rail before confirming. In addition, an icon appears on the right side of the currently selected field group which allows you to preview the structure of the fields it provides.
When previewing a field group, a detailed description of the field group’s schema is provided in the right rail. You can also navigate through the field group’s fields in the provided canvas. As you select different fields, the right rail updates to show details about the field in question. Select Back when you are finished previewing to return to the field group selection dialog.
For this tutorial, select the Demographic Details field group, then select Add field group.
The schema canvas reappears. The Field groups section now lists “Demographic Details” and the Structure section includes the fields contributed by the field group. You can select the field group’s name under the Field groups section to highlight the specific fields it provides within the canvas.
Within the Schema Editor, standard (Adobe-generated) classes and field groups are indicated with the padlock icon (. The padlock appears in the left rail next to the class or field group name, as well as next to any field in the schema diagram that is a part of a system-generated resource.
This field group contributes several fields under the top-level name person
with the data type “Person”. This group of fields describes information about an individual, including name, birth date, and gender.
Remember that fields may use scalar types (such as string, integer, array, or date), as well as any data type (a group of fields representing a common concept) defined within the Schema Registry.
Notice that the name
field has a data type of “Full name”, meaning it too describes a common concept and contains name-related sub-fields such as first name, last name, courtesy title, and suffix.
Select the different fields within the canvas to reveal any additional fields they contribute to the schema structure.
You can now repeat the same steps to add another field group. When you view the Add field group dialog this time, notice that the “Demographic Details” field group has been greyed out and the checkbox next to it cannot be selected. This prevents you from accidentally duplicating field groups that you have already included in the current schema.
For this tutorial, select the standard field groups Personal Contact Details and Loyalty Details from the list, then select Add field groups to add them to the schema.
The canvas reappears with the added field groups listed under Field groups in the Composition section, and their composite fields added to the schema structure.
The Loyalty Members schema is meant to capture data related to the members of a loyalty program, and the standard Loyalty Details field group that you added to the schema provides most of these, including the program type, points, join date, and more.
However, there may be a scenario where you want to include additional custom fields not covered by standard field groups in order to achieve your use cases. In the case of adding custom loyalty fields, you have two options:
To create a new field group, select Add in the Field groups sub-section like before, but this time select Create New Field group near the top of the dialog that appears. You are then asked to provide a display name and description for the new field group. For this tutorial, name the new field group “Custom Loyalty Details”, then select Add field groups.
As with class names, the field group name should be short and simple, describing what the field group will contribute to the schema. These too are unique, so you will not be able to reuse the name and must therefore ensure it is specific enough.
“Custom Loyalty Details” should now appear under Field groups on the left side of the canvas, but there are no fields associated with it yet and therefore no new fields appear under Structure.
Now that you have created the “Custom Loyalty Details” field group, it is time to define the fields that the field group will contribute to the schema.
To begin, select the plus (+) icon next to the name of the schema in the canvas.
An “Untitled Field” placeholder appears in the canvas, and the right rail updates to reveal configuration options for the field.
In this scenario, the schema needs to have an object-type field that describes the person’s current loyalty tier in detail. Using the controls in the right rail, start creating a loyaltyTier
field with type “Object” that will be used to hold your related fields.
Under Assign to, you must select a field group to assign the field to. Remember that all schema fields belong to either a class or a field group, and since this schema uses a standard class, your only option is to select a field group. Start typing in the name “Custom Loyalty Details”, then select the field group from the list.
When finished, select Apply.
The changes are applied and the newly created loyaltyTier
object appears. Since this is a custom field, it is automatically nested within an object namespaced to your organization’s tenant ID, preceded by an underscore (_tenantId
in this example).
The presence of the tenant ID object indicates that the fields you are adding are contained in your organization’s namespace.
In other words, the fields you are adding are unique to your organization and are going to be saved in the Schema Registry in a specific area accessible only to your organization. Fields you define must always be added to your tenant namespace to prevent collisions with names from other standard classes, field groups, data types, and fields.
Select the plus (+) icon next to the loyaltyTier
object to start adding sub-fields. A new field placeholder appears and the Field properties section is visible on the right side of the canvas.
Each field requires the following information:
The first field for the loyaltyTier
object will be a string called id
, representing the ID of the loyalty member’s current tier. The tier ID will be unique for each loyalty member, since this company sets different loyalty tier point thresholds for each customer based on different factors. Set the new field’s type to “String”, and the Field properties section becomes populated with several options for applying constraints, including default value, format, and maximum length. See the documentation on best practices for data validation fields to learn more.
Since id
will be a randomly generated freeform string, no further constraints are necessary. Select Apply to apply your changes.
Now that you have added the id
field, you can add additional fields to capture loyalty tier information such as:
To add each field to the schema, select the plus (+) icon next to the loyalty
object and fill in the required information.
When complete, the loyaltyTier
object will contain fields for id
, currentThreshold
, nextThreshold
, and effectiveDate
.
When defining fields in the Schema Editor, there are some additional options that you can apply to basic field types in order to provide further constraints on the data the field can contain. The use cases for these constrains are explained in the following table:
Constraint | Description |
---|---|
Required | Indicates that the field is required for data ingestion. Any data uploaded to a dataset based on this schema that does not contain this field will fail upon ingestion. |
Array | Indicates that the field contains an array of values, each with the data type specified. For example, using this constraint on a field with a data type of “String” specifies that the field will contain an array of strings. |
Enum & Suggested Values | An enum indicates that this field must contain one of the values from an enumerated list of possible values. Alternatively, you can also use this option to just provide a list of suggested values for a string field without constraining the field to those values. |
Identity | Indicates that this field is an identity field. More information regarding identity fields is provided later in this tutorial. |
Relationship | 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. The Relationship constraint indicates that this field references the primary identity of a schema based on a different class, implying a relationship between the two schemas. See the tutorial on defining a relationship for more information. |
Any required, identity, or relationship fields are listed in their respective sections in the left rail, allowing you to locate these fields easily regardless of the schema’s complexity.
For this tutorial, the loyaltyTier
object in the schema requires a new enum field that describes the tier class, where the value can only be one of four possible options. To add this field to the schema, select the plus (+) icon beside the loyaltyTier
object and fill in the required fields for Field name and Display name. For Type, select “String”.
Additional checkboxes appear for the field after its type has been selected, including checkboxes for Array, Enum & Suggested Values, Identity, and Relationship.
Select the Enum & Suggested Values checkbox, then select Enum. Here you can input the Value (in camelCase) and Display Name (an optional, reader-friendly name in Title Case) for each acceptable loyalty tier class.
When you have completed all field properties, select Apply to add the tierClass
field to the loyaltyTier
object.
The loyaltyTier
object now contains several fields and represents a common data structure that could be useful in other schemas. The Schema Editor allows you to readily apply reusable multi-field objects by converting the structure of those objects into data types.
Data types allow for the consistent use of multi-field structures and provide more flexibility than a field group because they can be used anywhere within a schema. This is done by setting the field’s Type value to that of any data type defined in the Schema Registry.
To convert the loyaltyTier
object to a data type, select the loyaltyTier
field in the canvas, then select Convert to new data type on the right side of the editor under Field properties.
A notification appears, confirming that the object has been successfully converted. In the canvas you can now see that the loyaltyTier
field now has a link icon, and the right rail indicates it has a data type of “Loyalty Tier”.
In a future schema, you could now assign a field as a “Loyalty Tier” type and it would automatically include fields for ID, tier class, point thresholds, and effective date.
You can also create and edit custom data types independently from editing schemas. See the guide on creating and editing data types for more information.
Your schema now contains several field groups in addition to the fields provided by its base class. When working with larger schemas, you can select the checkboxes next to field group names in the left rail to filter the displayed fields to only those provided by the field groups you are interested in.
If you are looking for a specific field in your schema, you can also use the search bar to filter displayed fields by name, regardless of which field group they are provided under.
The search function takes any selected field group filters into account when displaying matching fields. If a search query is not displaying the results you expect, you may need to double-check that you are not filtering out any relevant field groups.
The standard data structure that schemas provide can be leveraged to identify data belonging to the same individual across multiple sources, allowing for various downstream use cases such as segmentation, reporting, data science analysis, and more. In order to stitch data based on individual identities, key fields must be marked as Identity fields within applicable schemas.
Experience Platform makes it easy to denote an identity field through the use of an Identity checkbox in the Schema Editor. However, you must determine which field is the best candidate to use as an identity, based on the nature of your data.
For example, there may be thousands of loyalty program members belonging to the same loyalty level, and several that may share the same physical address. In this scenario, however, on enrollment each member of the loyalty program provides their personal email address. Since personal email addresses are usually managed by one person, the field personalEmail.address
(provided by the Personal Contact Details field group) is a good candidate for an identity field.
The steps outlined below cover how to add an identity descriptor to an existing schema field. As an alternative to defining identity fields within the structure of the schema itself, you can also use an identityMap
field to contain identity information instead.
If you plan on using identityMap
, keep in mind that it will override any primary identity you add to the schema directly. See the section on identityMap
in the basics of schema composition guide for more information.
Select the personalEmail.address
field in the canvas, and the Identity checkbox appears under Field properties. Check the box and the option to set this as the Primary identity appears. Select this box as well.
Each schema may contain only one primary identity field. Once a schema field has been set as the primary identity, you will receive an error message if you later attempt to set another identity field in the schema as the primary.
Next, you must provide an Identity namespace from the list of pre-defined namespaces in the dropdown. Since this field is the customer’s email address, select “Email” from the dropdown. Select Apply to confirm the updates to the personalEmail.address
field.
For a list of standard namespaces and their definitions, see the Identity Service documentation.
After applying the change, the icon for personalEmail.address
shows a fingerprint symbol, indicating that it is now an identity field. The field is also listed in the left rail under Identities.
Now all data ingested into the personalEmail.address
field will be used to help identify that individual and stitch together a single view of that customer. To learn more about working with identities in Experience Platform, please review the Identity Service documentation.
Real-Time Customer Profile leverages identity data in Experience Platform to provide a holistic view of each individual customer. The service builds robust, 360° profiles of customer attributes as well as timestamped accounts of every interaction customers have had across any system integrated with Experience Platform.
In order for a schema to be enabled for use with Real-Time Customer Profile, it must have a primary identity defined. You will receive an error message if you attempt to enable a schema without first defining a primary identity.
To enable the “Loyalty Members” schema for use in Profile, begin by selecting the schema title in the canvas.
On the right side of the editor, information is shown about the schema including its display name, description, and type. In addition to this information, there is a Profile toggle button.
Select Profile and a popover appears, asking you to confirm that you wish to enable the schema for Profile.
Once a schema has been enabled for Real-Time Customer Profile and saved, it cannot be disabled.
Select Enable to confirm your choice. You can select the Profile toggle again to disable the schema if you wish, but once the schema has been saved while Profile is enabled, it can no longer be disabled.
Within the Schema Editor you can also conduct quick actions to copy the JSON structure of the schema or delete the schema. Select More at the top of the view to display a drop down with quick actions.
A schema can be deleted within the UI from the Schema Editor using More actions and also from the schema details in the Browse tab. There are certain conditions that prevent a schema from being deleted. A schema cannot be deleted if:
Select Copy JSON structure to generate an export payload for any schema in the Schema Library. This action copies the JSON structure to your clipboard. Your exported JSON can then be used to import the schema, and any related resources, into a different sandbox or organization. This makes sharing and reusing schemas between different environments simple and efficient.
Now that you have finished composing the schema, you can see the complete schema in the canvas. Select Save and the schema will be saved to the Schema Library, making it accessible by the Schema Registry.
Your new schema can now be used to ingest data into Platform. Remember that once the schema has been used to ingest data, only additive changes may be made. See the basics of schema composition for more information on schema versioning.
You can now follow the tutorial on defining a schema relationship in the UI to add a new relationship field to the “Loyalty Members” schema.
The “Loyalty Members” schema is also available to be viewed and managed using the Schema Registry API. To begin working with the API, start by reading the Schema Registry API developer guide.
The Platform UI shown in the following videos are out of date. Please refer to the documentation above for the latest UI screenshots and functionality.
The following video shows how to create a simple schema in the Platform UI.
In this video, I’ll show you how to create schemas for Adobe Experience platform-based applications using the interface. For our example, I’ll create a simple loyalty system schema for our sample retail brand, Luma. There are a few things you need to have in place before you begin building your schema. First, you should have designed your data model and know what fields you need to capture. Here’s our entity relationship diagram for Luma. Second, you need access. An administrator needs to have granted you the permission items for data modeling. Now, we’re ready to go into the interface of any platform-based application and get to work. Select Schemas from the left navigation. Here is the Schemas Browse screen, where you can view and manage your existing schemas. There are column sorters, a search box, and filter options. Clicking the name of an existing schema will open the editor. But notice that if you click elsewhere on the row, you get this sidebar with additional metadata, including a JSON file with sample data to test the ingestion process. The schema ID is really helpful if you use the Schemas API. Let’s create our new schema. When I click Create Schema, I enter a workflow. On the first step of the workflow, I choose a base class for the schema. I have quick access to the two most common classes, Individual Profile for attribute data, and Experience Event for behavior. You can also select Other, where you can choose from a different Adobe class or create your own. Our loyalty data is attribute data, so I’ll select Individual Profile and then select Next. On the next step, I give my schema a name and an optional description. It shows me the fields that are automatically included as part of the Individual Profile class. Then I can click Finish. The easiest way to start adding fields is to just hit the plus button at the top of the schema, and then in the Field Name box, start typing what you’re looking for. I’ll type First Name. Since this is a very common field, a list of results come up, so we can quickly add it as a standard XDM field. Adobe provides a lot of standard fields out of the box to make your data modeling faster and simpler. Now, you’ll see that there are a few instances of first name fields. The difference is that these fields are in different field groups. Field groups are just groups of fields organized around a theme. You can preview the field group by clicking the icon. I see this group is oriented to B2B use cases, so it’s not what I want. Demographic details looks more promising. I also need Last Name in my schema too, and I can check both boxes to add them in one shot. If I decide later that I actually need more of those fields, I can select Manage Related Fields to open that view back up and check or uncheck more of those fields. Another way to add fields is to add an entire field group. The field groups shown are all compatible with the XDM individual profile class I’m using. If I were using the Experience event class, I might see different field groups. There are industry filters on the left. Filter the list to those most relevant to your industry. Here is a loyalty field group. Perfect. I can quickly add that to my schema. If I don’t want some of the fields, again I can use the Manage Related Fields option to open the group and remove individual fields. Business users at Luma prefer to call it Member Since instead of Join Date. Even though we call it a Standard Field, you can still customize the display name and description to whatever you want. The display name is what will appear to marketers in the Segment Builder, so they’ll be able to find it using familiar language. Now we have one remaining field in our ER diagram for CRMID, which doesn’t exist in any of the standard field groups. Let’s look at how to add that. Again, I’ll hit the plus button at the top of the schema and start typing my field name. And then I just hit enter to add it. You need to put it in a field group, which you can also do in this workflow. Now my new field appears and it will be namespaced under my tenant ID, Tech Marketing Demos, so it’s really clear that this is a custom field. You can also add custom fields within more logical locations. For example, if I want a field for Secret Agent Code Name, I can add that field directly in the Name object. This will extend the field group. Let’s have a look at what we’ve built so far. The Composition column has the high-level info. I can see my schema name, base class, and my field groups. Structure shows the fields which have been added to the schema. If I click on the name of the class, it will highlight all of the fields that are added by the class. If I click on the field group names, again, it will highlight the fields contributed by that group. You can also use the search box to quickly find a field. When I select a field, the Properties column shows me all of its details. I can also click back on the schema name to see the properties of the entire schema. So, our schema is mostly built. Two other big topics are Identity Fields and Enabling Schemas for Profile, but we’ve covered a lot and those are big topics too, so we’ll save them for additional videos. But at this point, you should know how to build schemas in the interface of any application built on Adobe Experience Platform.
The following video is intended to reinforce your understanding of working with field groups and classes.
In this video, I’ll show you how to build your own schema field groups in Adobe Experience Platform. Schema field groups are groups of fields used to build Experience Platform data models and are usually organized around a theme. For example, you could have a field group for loyalty data, paid search marketing details, or dining reservation details. Platform comes with many field groups out of the box, reflecting common industry data model best practices. Sometimes though, you may have your own specific modeling requirements which aren’t met by the out-of-the box field groups. In these circumstances, you can easily create your own field groups to meet your needs. I’ll show you how to create a field group in the Platform interface, although you can also create these via the API as well. I’ll log into the Platform interface and select Schemas in the left navigation. I can click the Field groups tab to see all of the field groups in my account, and can use the filter to see the ones that I’ve created. Field groups are created in the schema editor. So, I can either start the process to build the new schema or open an existing schema. While designing the data model for Luma, our retail demo brand, we realized we needed a custom class for our brick and mortar store details. We created a class containing our StoreId field, and we’ll now create a field group for the store contact details. I’ll create a new schema using my custom store class. Next, I’m prompted to add a field group. Field groups are almost always tied to a specific class. So, while there are field groups that contain address information, they won’t be compatible with my new Store class. There are a few standard groups that we make available to all classes, which is what we see here. I want to create a new field group, so I click Create new field group and give it a name and description. Now, I can start adding fields wherever I’d like to in this schema. I’ll add a field at the root level. Note that custom fields are always namespaced under my organization’s tenant ID to prevent collisions with standard fields. Now, although I can’t use other standard field groups for my class, I can access any of the standard data types. I can quickly add my postal address details by adding the Postal address data type which contains a number of relevant fields. I can quickly do the same for phone number. Note that the field names should all be one word and you need to assign a display name, which should be a friendly name so that downstream users, like marketers, can easily find the relevant fields when doing things like building segments off of them. For my Store Name field. I’ll use a more generic data type string. When I save my schema, the new field group will be saved and it will be reusable in any other schema sharing the same base class. So, that’s how to create field groups in Adobe Experience Platform, good luck. -
The following sections provide addition information information regarding the use of the Schema Editor.
Experience Platform provides the flexibility to define a schema based on a class that is unique to your organization. To learn how to create a new class, see the guide on creating and editing classes in the UI.
You can change the class of a schema at any point during the initial composition process before the schema has been saved.
Reassigning the class for a schema should be done with extreme caution. Field groups are only compatible with certain classes, and therefore changing the class will reset the canvas and any fields you have added.
To learn how to change the class of a schema, see the guide on managing schemas in the UI.