This article will address everything you need to know to understand the below. For a guide on how to setup your Unique Identifier mapping(s), see the "Field Mapping Setup Guide" for your respective integration. These can be found in our Integrations Section.
- What a Unique Identifier (UIS) is
- How UIDs are generally used
- How ClientSuccess uses UIDs
- Using multiple UIDs
- Unique IDs vs. Traditional Mappings
What is a Unique Identifier?
Unique identifiers, or UIDs, are some unique combination of numbers/letters that are assigned to an individual record, or group of data points. As technology becomes an ever-present part of our lives, UIDs are becoming more and more commonplace.
From Amazon order numbers, to your drivers license or passport ID, to the serial numbers on your computer, UIDs provide a unique "fingerprint" that will only ever be associated with one set of data.
There might be thousands of orders that Amazons processes each day, but each one is assigned an ID that is unique to that order, and will never be used again. That way, when you need to look up a specific order, you need only input your unique order number, and you can confidently retrieve details about the order you're looking for.
How are UIDs used?
Using the Amazon example, Amazon is going to have a variety of softwares it uses in order to manage an order from the time you place it, until it shows up on your doorstep. Between the website where you make the purchase, the warehouse that packages the order, the delivery service that transports your order, to the customer service team that helps you resolve potential issues, there needs to be one UID that can connect all of those things together.
The same is true on a smaller, purely digital scale as well. When you have a record in a system such as Salesforce or Zendesk, if you want those systems to be able to communicate with each other, and pass data back and forth, you're going to need an ID that is shared between the two systems. That way, when changes are made in Salesforce, and you want those changes to push to Zendesk to update some field there, there's a connection between the two systems that helps them know where data should be updated.
How does ClientSuccess leverage UIDs?
ClientSuccess integrates with a variety of, what we'll refer to as, "external systems". Each time ClientSuccess pings your external system and finds updates that need to be imported into ClientSuccess, we need to know how to connect these updates between your external system records and ClientSuccess records. There are essentially two types of updates:
- New records (Customers/Contacts) you've created that do not yet exist in ClientSuccess, and need to now be imported into ClientSuccess as Clients/Contacts.
- Existing records (Customers/Contacts) that have been updated in your external system, and those updates need to be replicated within the Client/Contact they're paired up to in ClientSuccess.
How do we know whether to create a new record vs. update an existing one; UIDs. Every software groups related data points into bodies of information (For Salesforce: think Accounts, Contacts, Opportunities, Users etc., for HubSpot: think Companies, Contacts, Deals etc.). They will also have a unique combination of letters and/or numbers that make up a UID that will serve as a record's "fingerprint", which is native to that software.
As it relates to Salesforce (our most popular integration), these would be your Account IDs, Contact IDs, Opportunity IDs etc. Here's an example of an Account ID which can be found in the Salesforce URL when viewing an individual Account:
When setting up their Salesforce integration, most customers will simply leverage the native record ID (Account, Contact etc.) as their UID. However, if you have an alternative ID, such as an ID that comes directly from your own product that you would prefer to use, and that ID is stored in your external system, that is an option as well.
Other systems follow similar patterns of having UIDs native to their records; HubSpot Company IDs, Zendesk Organization IDs etc.
For your Client object mappings, a typical UID setup would look like the below. On the ClientSuccess side, UID mappings labels will always be preceded with "ID -":
Above is the Client mapping you'll use should you choose to use the Salesforce Account ID (standard) as your Client/Account level UID.
Using multiple UIDs
There may be some cases where multiple UIDs are needed to establish a successful sync. If you believe you may need multiple UID criteria to be considered in addition to the base "ID - CRM ID" mapping, please reach out to your CSM to consult with them on this.
Some additional UID mappings may include "ID - Name [Lookup]" (this looks at your Client Name as a UID) and "ID - External ID" (looks at your Client level "External ID" field as a UID).
Unique IDs vs. Traditional Mappings
The function of a UID mapping it not really to bring data into ClientSuccess, per se. Rather, UID mappings establish the connection between two existing data points.
The first time you run an import from Salesforce, your UIDs will be brought into ClientSuccess and stored in our "ID - CRM ID" field, establishing the connection. The "ID - CRM ID" field is not exposed in the ClientSuccess UI, it's a data point in the back-end.
Your other field mapping types will be the ones that actually sync field values back and forth between systems as they're updated. Knowing this, you may end up mapping the same Salesforce field twice.
In the example below, the Salesforce Account ID is used as the UID for the Client sync. The "ID - CRM ID" field is not exposed in the ClientSuccess UI, so what do you do if you need to visibly see the Salesforce Account ID, in the ClientSuccess UI?
One option would be to map the Account ID to import into ClientSuccess via a custom field:
For more details on how to setup your UIDs, as well as other mappings, please see the "Field Mapping Setup Guide" for your respective integration. These can be found in our Integrations Section.