Contacts: a technical overview
A technical overview of the contact for administrators and developers.
A contact represents an individual who interacts with or may potentially interact with your organization. Contacts are stored in the Sitecore Experience Database (xDB) which is the central repository for contact and experience data in Sitecore. The xDB contains the most recent version of your contacts. The contact entity is like a container for all the information that you collect about an individual.
The contact entity contains multiple data entries, which are grouped into facets and stored in the xDB. Some information, for example interactions or outcomes, is stored in related entities. You have various options when extending the contact data model, such as implementing a custom contact facet or extending an additional one.
Contacts are identified by their unique identifier. This is a GUID-based Sitecore identifier, and optionally, by their string-based custom identifier, such as an e-mail address. Both are guaranteed to be unique within the xDB. Contacts that have a string-based custom identifier set are referred to as known contacts.
Before modifying related data, the contact must be locked. This ensures that contacts cannot be modified while they are locked by another content delivery cluster or a background process.
You can import new and update existing contacts using the bulk import classes in the API. bulk import enables you to create a process which allows you to import contacts from other systems and keep existing contacts up to date. Additionally, you can use the interaction registry to import and register other interactions associated with these contacts.
Bulk update only supports known contacts that have already been identified because an external identifier is required to map an external contact to an existing contact in the xDB.
You can use several extension points to customize the import process, providing you with greater control over the process that copies contact data from an external data source onto contacts in the xDB.
Contact processing is a background service that allows different parts of the system, such as indexing, to subscribe to the triggered event that happens when you create or modify a contact.
Each time a contact is inserted, modified, or deleted, the event is queued up for processing along with the type of modification that has been made. For example, if indexing subscribes to this event, then any changes made to a contact will be communicated to the search engine crawler so that the searches indexes can be updated.
It is also possible to schedule contact processing manually, for example, if you have created your own custom event handler for contact processing. To customize contact processing, there is a pipeline extension point you can use to register any custom code that you want to be executed when a contact is processed. This contact processing event is triggered on the processing server role.