Within your private data tenant, your customer records are grouped together by Link ID. For each unique person identity, as determined by Verato’s matching algorithm, there is a single Link ID with one or more of your customer records grouped by the Link ID.
For example: If you have a single customer record for Sally Smith, then the Link ID for Sally Smith is only associated with a single record. If you have three customer records for Sally Smith, then the Link ID for Sally Smith is associated with three of your customer records.
Each customer record is uniquely identified by the source system from which it came—the Source ID—plus a unique local identifier within that source system/application, called the Native ID.
Source and Native IDs
The combination of Source + Native ID uniquely identifies each of your customer records. This is important, in part, because you may have updates to the data values for a given customer record in your local source system/application, and you communicate those updates to the Universal Identity platform using the Source + Native ID.
If Universal Identity platform has already seen this Source + Native ID from you before, then it knows you have provided an update to an existing record rather than a new record. The Source value should be a unique code that represents the source from which a given record came from – it may not contain any whitespace characters in the source code.
Important characteristics of Source Values
- Source values are added to a configuration system for your instance of Universal Identity, along with the mapping of which sources can be accessed by which user accounts.
- Source values are case-sensitive.
- It is important that the source values added to the Universal Identity platform configuration match the source values passed in as web service requests – if they do not match, you will not get expected results from your web service response.
Verato recommends a naming convention for Sources of
client_name.source_code. For example, for client XYZ Bank, who is providing data from sources CRM and Accounts, the source values might be “XYZBank.CRM” and “XYZBank.Accounts”. How Link IDs can be changed
Link IDs typically change for one of the following reasons
- New Record joins an existing Link ID. This can only be done through the postIdentity API call.
- Updated Record causes record to join a different Link ID. This can only be done through the postIdentity API call.
- Records are Merged or Unmerged . This can be done through an API call or through the user interface.
- Records are linked or unlinked. This can be done through an API call or through the user interface.
How to know if a Link ID has changed and review information
When source records are posted to Universal Identity for a second (or third or Nth) time, in some cases the addition of new attribute values allows Universal Identity to recognize that two previously-distinct identities (with separate Link IDs) are actually the same person.
When this happens, one or more of the source records will have their Link ID assignment changed from one value to a new value. When this happens, Universal Identity generates a notification message with the details of this change in Link ID assignment.
If a Link ID changes through an API call or through a user action from the user interface, you can get information about the change through one of the following methods.
- Through the Events section in the API response. This will only tell you if a Link ID was changed by an API call (linkIdentities, unlinkIdentities, mergeIdentities, unmergeIdentities, or deleteSourceIdentity) that caused the response.
Changes made via API are synchronized in real-time and represent up-to-the-minute (or close) changes, but only reflect changes caused by the API call that caused the change.
- Through Notifications. Notifications list all of the Link ID changes in the past 24 hours. They are not synchronized in real time, but include ALL changes made by any source, i.e. API calls, changes made from the user interface, etc.