Data subject entities in your Sitecore implementation

Abstract

Overview of where and how data subject's personal data are stored as users, contacts, enrollments and customers.

Warning

This Privacy Guide provides technical guidance on how your developers can choose to configure your Sitecore product implementation to support you on your data privacy compliance journey. 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 data. Your resulting implementation is based entirely on your own configuration choices.

A data subject is represented by four separate entities across the platform:

  • As users in an Experience Manager (XM) context.

  • As contacts in an Experience Platform (XP) context.

    • As enrollments in the Marketing Automation database.

  • As customers in an Experience Commerce (XC) context.

  • 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 data and entities are linked directly or indirectly by IDs or other identifiers. When securing the platform and implementing functionality that supports the data subject’s rights, you must consider all representations of the data subject across the platform and how they are linked.

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 depends on your implementation. These tables describe the model for collecting data that is available by default.

Contact

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 data is enabled):

  • Contact identifiers

  • Contact facets, including personal data 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

Default facets and events

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

Email Experience Manager facets and events

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

Commerce Connect facets and events

Before 9.0.2, some Commerce Connect events store personal data such as username and email. For more information, see  Items installed with Commerce Connect.

In 9.0.2 and later, personal data associated with events is stored in contact facets marked [PIISensitive]. Events do not store personal data, but may include properties that reference contact facets. If the data subject chooses to be forgotten, all personal data is removed and the link between an event and personal data 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 may reveal sensitive information about the data subject's interaction with a brand or organization.

Note

You can add custom data to enrollments. Sitecore recommends that you do not add personal data such as email addresses to an enrollment.

API

Marketing Automation Operations API

Customer

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

Email address and shipping address stored as part of an order, even for anonymous customers.

API

Commerce Service API

User

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 under Links between data subject 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 data such as a data subject’s name and email address.

API

Reporting API, SQL

The following table details how data subject 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 includes the customer’s ID and a prefix. If you are using the Sitecore Commerce Engine, the ExternalId looks like this: 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 includes the customer’s ID and a prefix. If you are using the Sitecore Commerce Engine, the ExternalId looks like this: 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, 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.