Entities that represent individuals in your Sitecore implementation

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

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

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

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 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.

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.

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_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 contact

Enrollments include a reference to the contact's ID.

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.

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_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 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,