Entities that represent individuals in your Sitecore implementation

Current version: 9.3

Warning

This Privacy Guide provides technical guidance on how your developers can choose to configure your Sitecore product implementation to support you with data privacy compliance. This guide does not provide exhaustive guidance, and should not be construed or used as legal advice about the content, interpretation, or application of any law or regulation. You, the customer, will always be in the best position to assess your own risks, and must seek your own legal counsel to understand the applicability of any law or regulation to your business, including how you process personal information. Your resulting implementation is based entirely on your own configuration choices.

An individual is represented by four separate entities across the platform:

As contacts in an Experience Platform (XP) context.
As enrollments in the Marketing Automation database.
As customers in an Experience Commerce (XC) context.
As users in an Experience Manager (XM) context.

It is also represented as form metrics data in the xDB Reporting database, which links to form submission data in the Forms database.

Each entity has the potential to store sensitive personal information and entities are linked directly or indirectly by IDs or other identifiers. When securing the platform and implementing functionality that supports the individual’s rights, you must consider all representations of the individual across the platform and how they are linked.

Where and how data is stored

The following tables describe the purpose of each entity, where the entity is stored, and what data can be associated with each entity.

Important

The exact data that is collected by you depends on your implementation. These tables describe the model for collecting data that is available by default. Where it is stored depends on whether you are self-hosting or hosting in the Managed Cloud environment.

Contacts

Purpose	Central storage for data relevant to marketing activities such as personalization, automation, and email.
Storage	Collection database, xDB index
Data	If collected, the following data is available in the Collection database and the xDB index (assuming indexing of personal information is enabled): Contact identifiers Contact facets, including personal information such as: First and last name Address Email address, including a historical list of emails for EXM Commerce-specific data such as orders and carts, including the associated address and email address Interactions, including: Events Outcomes Goals Page views Interaction facets
API	xConnect Client API

See the xConnect collection model reference for a list of all default xConnect facets and events. Facets with personal information are marked [PIISensitive].

The Email Experience Manager (EXM) EmailAddressHistory contains personal information. This facet is marked [PIISensitive].

Personal information associated with events is stored in contact facets marked [PIISensitive]. Events do not store personal information, but might include properties that reference contact facets. If the individual chooses to be erased, all personal information is removed and the link between an event and personal information in a contact facet is broken.

Enrollments

Purpose	Represents a contact's enrollment in an automation plan or activity.
Storage	Marketing Automation database
Data	The following data is available in the Marketing Automation database: Contact ID Plans or activities that the contact is enrolled in. Plan or activity names might reveal sensitive information about the individual's interaction with a brand or organization. Note You can add custom data to enrollments. We recommend that you do not add personal information such as email addresses to an enrollment.
API	Marketing Automation Operations API

Customers

Purpose	Receive and pay for submitted orders.
Storage	Shared Environments database, Customers Scope index
Data	The following data is available in the Shared Environments database and Customers Scope index: Customer details, such as name and address Customer orders See Customer entity Note The email address and shipping address are stored as part of an order, even for anonymous customers.
API	Commerce Service API

Users

Purpose	Authentication and authorization.
Storage	The default implementation of ASP.NET Membership stores users in the Core database. There is no default provider for ASP.NET Identity.
Data	Username ASP.NET membership profile data
API	ASP.NET Membership API or ASP.NET Identity API

Forms

Purpose	Metrics such as form submission successes and failures are aggregated into the xDB Reporting database. Each record includes a `ContactId`, `InteractionId`, and `FieldId`. Form submissions are stored in the Forms database, and include a `FieldItemId`. The records can be linked to a contact in the Collection database as follows. Refer to the table in the next section, Links between individual entities, for more information.
Storage	xDB Reporting database, specifically: Fact_FormMetrics table (includes ContactID and InteractionID) Fact_FormFieldMetrics table (includes InteractionID) Forms database, specifically: FieldData table (includes form submission data)
Data	Form submission data is customizable and can include personal information such as an individual’s name and email address.
API	Reporting API, SQL

Links between individual entities

The following table details how individual entities are linked in a default implementation that uses Commerce Connect to link Experience Platform and Experience Commerce.

Links to the customer entity

From contact to customer	There is no direct link between a contact and a customer. Indirect link via contact to user (assuming an identifier exists), user to customer.
From user to customer	The user entity has an `ExternalId` property that includes the customer’s ID and a prefix. If you are using the Sitecore Commerce Engine, the `ExternalId` looks like the following: Entity-Customer-6c639677c824494bbf64c1049312233e. In this case, 6c639677c824494bbf64c1049312233e is the customer ID.
From form submission to customer	There is no direct link between a form submission and a customer. Indirect link via form data to contact, contact to user (assuming an identifier exists), user to customer.
From enrollment to customer	There is no direct link between an enrollment and a customer.

Links to the enrollment entity

From customer to enrollment	There is no direct link between an enrollment and a customer.
From contact to enrollment	Enrollments include a reference to the contact's ID.
From user to enrollment	There is no direct link between an enrollment and a user.
From form submission to enrollment	The `Fact_FormMetrics` table contains a `ContactID` column. You can use the xConnect Client API to retrieve a contact by ID and use that ID to look up enrollments.

Links to the contact entity

From customer to contact	There is no direct link between a contact and a customer. Indirect link via customer to user, user to contact (assuming an identifier exists).
From user to contact	By default, there is no link between a contact entity and a user entity. To create a link, you must add a known identifier to the contact that includes an identifier string (such as the username) and a source string (such as ‘extranet’). This can be done using the xConnect Client API, or using the `IdentifyAs()` method in a tracking context. If you are using Commerce Connect, a known identifier is automatically added to a contact when a user is created. The identifier is the username, and the source is `Sitecore.Commerce.Constants.ContactSource`. If you are not using Commerce Connect, you must create this relationship yourself. A contact can have multiple identifiers that links them to different systems. You must know which identifier source your system is using for identifiers that correspond to a user entity.
From form submission to contact	The `Fact_FormMetrics` table contains a `ContactID` column. You can use the xConnect Client API to retrieve a contact by ID. The `Fact_FormFieldMetrics`contains an `InteractionID` column. You can look up the corresponding entry in the `Fact_FormMetrics` table, which also contains the `ContactID` column.
From enrollment to contact	Enrollments include a reference to the contact's ID.

Links to the user entity

From customer to user	The user entity has an `ExternalId` property that includes the customer’s ID and a prefix. If you are using the Sitecore Commerce Engine, the `ExternalId` looks like the following: Entity-Customer-6c639677c824494bbf64c1049312233e. In this case, 6c639677c824494bbf64c1049312233e is the customer ID.
From contact to user	By default, there is no link between a contact entity and a user entity. To create a link, you must add a known identifier to the contact that includes an identifier string (such as the username) and a source string (such as ‘extranet’). This can be done using the xConnect Client API, or using the `IdentifyAs()` method in a tracking context. If you are using Commerce Connect, a known identifier is automatically added to a contact when a user is created. The identifier is the username, and the source is `Sitecore.Commerce.Constants.ContactSource`. If you are not using Commerce Connect, you must create this relationship yourself. A contact can have multiple identifiers that links them to different systems. You must know which identifier source your system is using for identifiers that correspond to a user entity.
From form submission to user	There is no direct link between a user and form submissions. Indirect link via user to contact (assuming an identifier exists), contact to form submission.
From enrollment to user	There is no direct link between a user and an enrollment.

Links to form submissions

From customer to form submission	There is no direct link between a customer to a form submission. Indirect link via user to contact, contact to form submission.
From user to form submission	There is no direct link between a customer to a form submission. Indirect link via user to contact (assuming an identifier exists), contact to form submission
From contact to form submission	The `Fact_FormMetrics` table contains a `ContactID` column. You can use the xConnect Client API to retrieve a contact by ID. The `Fact_FormFieldMetrics`contains an `InteractionID` column. You can look up the corresponding entry in the `Fact_FormMetrics` table, which also contains the `ContactID` column.
From enrollment to form submission	The `Fact_FormMetrics` table contains a `ContactID` column. You can use the xConnect Client API to retrieve a contact by ID and use that ID to look up enrollments.

Do you have some feedback for us?

If you have suggestions for improving this article,