Partner schema configuration
Experience Platform uses schemas to describe the structure of data in a consistent and reusable way. When you ingest data into Experience Platform, it is structured according to an XDM schema. For more information on the schema composition model, including design principles and best practices, see the basics of schema composition.
When building a destination with Destination SDK, you can define your own partner schema to be used by your destination platform. Use the partner schema to map profile attributes from Experience Platform to specific fields that your destination platform recognizes, all within the Experience Platform UI.
When configuring the partner schema for your destination, you can fine tune the field mapping supported by your destination platform, such as:
- Map a
phoneNumberXDM attribute to aphoneattribute supported by your destination platform. - Create dynamic partner schemas that Experience Platform can dynamically call to retrieve a list of all supported attributes within your destination.
- Define mandatory field mappings that your destination platform requires.
To understand where this component fits into an integration created with Destination SDK, see the diagram in the configuration options documentation or see the guide on how to use Destination SDK to configure a file-based destination.
You can configure your schema settings via the /authoring/destinations endpoint. See the following API reference pages for detailed API call examples where you can configure the components shown in this page.
This article describes all the supported schema configuration options that you can use for your destination, and shows what you see in the Experience Platform UI.
Supported integration types supported-integration-types
Refer to the table below for details on which types of integrations support the functionality described on this page.
Supported schema configuration supported-schema-types
Destination SDK supports multiple schema configurations:
- Static schemas are defined through the
profileFieldsarray in theschemaConfigsection. In a static schema, you define every target attribute that should be shown in the Experience Platform UI in theprofileFieldsarray. If you need to update your schema, you must update the destination configuration. - Dynamic schemas use an additional destination server type, called a dynamic schema server, to dynamically retrieve the supported target attributes and generate schemas based on your own API. Dynamic schemas do not use the
profileFieldsarray. If you need to update your schema, there is no need to update the destination configuration. Instead, the dynamic schema server retrieves the updated schema from your API. - Within the schema configuration, you have the option of adding required (or predefined) mappings. These are mappings that you can view in the Experience Platform UI, but you cannot modify them when setting up a connection to your destination. For example, you can enforce the email address field to always be sent to the destination.
The schemaConfig section uses multiple configuration parameters, depending on the type of schema that you need, as shown in the sections below.
Create a static schema attributes-schema
To create a static schema with profile attributes, define the target attributes in the profileFields array as shown below.
"schemaConfig":{
"profileFields":[
{
"name":"phoneNo",
"title":"phoneNo",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the mobilePhone.number value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"firstName",
"title":"firstName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.firstName value in Experience Platform could be firstName on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"lastName",
"title":"lastName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.lastName value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
}
],
"useCustomerSchemaForAttributeMapping":false,
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true,
"segmentNamespaceAllowList": ["someNamespace"],
"segmentNamespaceDenyList": ["someOtherNamespace"]
}
profileFieldsprofileFields array, you can omit the useCustomerSchemaForAttributeMapping parameter entirely.useCustomerSchemaForAttributeMappingEnables or disables the mapping of attributes from the customer schema to the attributes that you define in the profileFields array.
- If set to
true, you only see the source column in the mapping field.profileFieldsare not applicable in this case. - If set to
false, you can map source attributes from your schema to the attributes you defined in theprofileFieldsarray.
The default value is false.
profileRequiredtrue if you should be able to map profile attributes from Experience Platform to custom attributes on your destination platform.segmentRequiredtrue.identityRequiredtrue if you should be able to map identity types from Experience Platform to the attributes you defined in the profileFields array.segmentNamespaceAllowListUse of this parameter is discouraged in most cases. Instead, use
"segmentNamespaceDenyList":[] to allow all types of audiences to be exported to your destination.If both
segmentNamespaceAllowList and segmentNamespaceDenyList are missing from your configuration, you can only export audiences originating from the Segmentation Service.segmentNamespaceAllowList and segmentNamespaceDenyList are mutually exclusive.segmentNamespaceDenyListAdobe recommends allowing the export of all audiences, regardless of the origin, by setting
"segmentNamespaceDenyList":[].Important: If you do not specify
segmentNamespaceDenyList in your schemaConfig and you do not use segmentNamespaceAllowList, the system automatically sets segmentNamespaceDenyList to []. This prevents the loss of custom audiences in the future. For safety, Adobe recommends explicitly setting "segmentNamespaceDenyList":[] in your configuration.segmentNamespaceAllowList and segmentNamespaceDenyList are mutually exclusive.The resulting UI experience is shown in the images below.
When you select the target mapping, you can see the fields defined in the profileFields array.
After selecting the attributes, you can see them in the target field column.
Create a dynamic schema dynamic-schema-configuration
Destination SDK supports the creation of dynamic partner schemas. As opposed to a static schema, a dynamic schema does not use a profileFields array. Instead, dynamic schemas use a dynamic schema server which connects to your own API from where it retrieves the schema configuration.
In a dynamic schema configuration, the profileFields array is replaced by the dynamicSchemaConfig section, as shown below.
"schemaConfig":{
"dynamicSchemaConfig":{
"dynamicEnum": {
"authenticationRule":"CUSTOMER_AUTHENTICATION",
"destinationServerId":"DYNAMIC_SCHEMA_SERVER_ID",
"value": "Schema Name",
"responseFormat": "SCHEMA"
}
},
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true
}
dynamicEnum.authenticationRuleIndicates how Experience Platform customers connect to your destination. Accepted values are CUSTOMER_AUTHENTICATION, PLATFORM_AUTHENTICATION, NONE.
- Use
CUSTOMER_AUTHENTICATIONif Experience Platform customers sign in to your system via any of the authentication methods described in the customer authentication documentation. - Use
PLATFORM_AUTHENTICATIONif there is a global authentication system between Adobe and your destination and the Experience Platform customer does not need to provide any authentication credentials to connect to your destination. In this case, you must create a credentials object using the Credentials API and pass the credential object’s ID in theauthenticationIdparameter in the destination delivery configuration. - Use
NONEif no authentication is required to send data to your destination platform.
dynamicEnum.destinationServerIdinstanceId of your dynamic schema server. This destination server includes the API endpoint which Experience Platform calls to retrieve the dynamic schema.dynamicEnum.valuedynamicEnum.responseFormatSCHEMA when defining a dynamic schema.profileRequiredtrue if you should be able to map profile attributes from Experience Platform to custom attributes on your destination platform.segmentRequiredtrue.identityRequiredtrue if you should be able to map identity types from Experience Platform to the attributes you defined in the profileFields array.Required mappings required-mappings
Within the schema configuration, in addition to your static or dynamic schema, you have the option of adding required (or predefined) mappings. These are mappings that you can view in the Experience Platform UI, but you cannot modify them when setting up a connection to your destination.
For example, you can enforce the email address field to always be sent to the destination.
- You can configure a required source field and a required destination field. In this case, you cannot edit or select either field and can only view the selection.
- You can configure a required destination field only. In this case, you can select a source field to map to the destination.
See below two examples of a schema configuration with required mappings and what these look like in the mapping step of the activate data to batch destinations workflow.
The example below shows both required source and destination mappings. When both source and destination fields are specified as required mappings, you cannot select or edit either field, and can only view the predefined selection.
| code language-json |
|---|
|
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
|---|---|---|---|
| Parameter | Type | Required/Optional | Description |
requiredMappingsOnly |
Boolean | Optional | When this is set to true, you cannot map other attributes and identities in the activation flow, apart from the required mappings that you define in the requiredMappings array. |
requiredMappings.sourceType |
String | Required |
Indicates the type of the
|
requiredMappings.source |
String | Required |
Indicates the value of the source field. Supported value types:
|
requiredMappings.destination |
String | Required | Indicates the value of the target field. When both source and destination fields are specified as required mappings, you cannot select or edit either field and can only view the selection. |
As a result, both the Source field and Target field sections in the Experience Platform UI are turned off.
The example below shows a required destination mapping. If only the destination field is specified as required, you can select what source field to map to it.
| code language-json |
|---|
|
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
|---|---|---|---|
| Parameter | Type | Required/Optional | Description |
requiredMappingsOnly |
Boolean | Optional | When this is set to true, you cannot map other attributes and identities in the activation flow, apart from the required mappings that you define in the requiredMappings array. |
requiredMappings.destination |
String | Required | Indicates the value of the target field. When only the destination field is specified, you can select a source field to map to the destination. |
mandatoryRequired |
Boolean | Optional | Indicates whether the mapping should be marked as a mandatory attribute. |
primaryKeyRequired |
Boolean | Optional | Indicates whether the mapping should be marked as a deduplication key. |
As a result, the Target field section in the Experience Platform UI is turned off, while the Source field section is active and you can interact with it. The Mandatory key and Deduplication key options are active, and you cannot change them.
Configure support for external audiences external-audiences
To configure your destination to support the activation of externally generated audiences, include the snippet below in the schemaConfig section.
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
See the property descriptions in the table further above on this page to learn more about the segmentNamespaceDenyList functionality.
Next steps next-steps
You now understand the static and dynamic schema types supported by Destination SDK, how to add required mappings, and how to configure your destination to support external audiences.
To learn more about the other destination components, see the following articles: