1. Personal data in Sitecore

Entities that represent individuals in your Sitecore implementation

Version:
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

PurposeCentral storage for data relevant to marketing activities such as personalization, automation, and email.
StorageCollection database, xDB index
DataIf 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:
  • Interactions, including:
  • Interaction facets
APIxConnect Client API

Default facets and events

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

Email Experience Manager facets and events

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

Commerce Connect facets and events

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

PurposeRepresents a contact's enrollment in an automation plan or activity.
StorageMarketing Automation database
DataThe 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.

APIMarketing Automation Operations API

Customers

PurposeReceive and pay for submitted orders.
StorageShared Environments database, Customers Scope index
DataThe 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.

APICommerce Service API

Users

PurposeAuthentication and authorization.
StorageThe 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
APIASP.NET Membership API or ASP.NET Identity API

Forms

PurposeMetrics 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.
StoragexDB Reporting database, specifically:

  • Fact_FormMetrics table (includes ContactID and InteractionID)
  • Fact_FormFieldMetrics table (includes InteractionID)


Forms database, specifically:

  • FieldData table (includes form submission data)
DataForm submission data is customizable and can include personal information such as an individual’s name and email address.
APIReporting API, SQL

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

From contact to customerThere 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 customerThe 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 customerThere 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 customerThere is no direct link between an enrollment and a customer.
From customer to enrollmentThere is no direct link between an enrollment and a customer.
From contact to enrollmentEnrollments include a reference to the contact's ID.
From user to enrollmentThere is no direct link between an enrollment and a user.
From form submission to enrollmentThe 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.
From customer to contactThere 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 contactBy 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 contactThe Fact_FormMetrics table contains a ContactID column. You can use the xConnect Client API to retrieve a contact by ID. The Fact_FormFieldMetricscontains an InteractionID column. You can look up the corresponding entry in the Fact_FormMetrics table, which also contains the ContactID column.
From enrollment to contactEnrollments include a reference to the contact's ID.
From customer to userThe 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 userBy 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 userThere 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 userThere is no direct link between a user and an enrollment.
From customer to form submissionThere 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 submissionThere 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 submissionThe Fact_FormMetrics table contains a ContactID column. You can use the xConnect Client API to retrieve a contact by ID. The Fact_FormFieldMetricscontains 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 submissionThe 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.
If you have suggestions for improving this article, let us know!