When building integrations between Salesforce and external systems, there is often a need to keep the data in synch. In order to relate data in Salesforce with their counterparts in the external system we have two options. One option is that we keep either the Salesforce 18 character opaque identifier field for an object in the external system. The second option is to create a field in Salesforce that will store the unique identifier from the external system in Salesforce. The latter field is called an External ID, and using it has a number of advantages when developing integrations.
About the Salesforce External ID
Salesforce allows custom fields on standard objects and custom objects to be identified by the attribute of External ID. Up to seven fields per custom or standard object can be given the external id attribute. When a field is marked with this attribute it becomes searchable from the sidebar and by default, Salesforce will create an index for the field. The index allows queries to reference that field faster. Custom fields of type text, number or Email can have the External ID attribute enabled.
The External ID feature is extremely useful when performing integration and data migration with Salesforce.
1. Identifying the System of Record – To keep Salesforce data synchronized with an external system, create a custom field with the external id attribute and store the unique identifier from the external system. To perform updates to the Salesforce object when changes occur in the data in the external system, use the Salesforce Upsert operation with the external id attribute as the field for matching on the object instead of the Salesforce id field. Middleware tools can easily perform the above upsert operation based on the changed records in the source systems. For updates in the other direction, Salesforce to the external system, having the Salesforce field with the external id attributes obviates the need to store the Salesforce identifier in the external system to sync changes in Salesforce with the external system.
2. Maintaining Relationships – When loading data into objects that have lookup or master detail relationships, using the External ID avoids having to perform manual or multiple steps using tools such as Excel to associate the Salesforce ID of the related or parent object. For example, when loading new Contacts, we need the Salesforce id of the related Account object, so that the Contact gets created under the related Account. In the integration setup, this would require the external system to know of the Salesforce id of the Account. If the Account object has an External ID field, it can be used instead of the Account Salesforce id with the Salesforce Upsert operation to load Contacts. Most middleware tools including Salesforce dataloader supports this feature.
3. Hierarchical relationships – When bringing in external data in the form of GrandParent -> Parent -> Child into Salesforce efficiently, using External Id and upsert offers a powerful way to load the data without dealing with Salesforce Ids at all. As long as the data is arranged such that the grandparents, parents and children are loaded in that order, and in separate batches, Salesforce will magically load the data with the right hierarchical relationships.
Some Best Practices
- Use the unique attribute along with the External Id attribute to ensure uniqueness of the External ID field.
- Build the External Id as a combination of one or more fields from the system of record to ensure uniqueness.
In conclusion, familiarizing yourself with the way External IDs can be used will save you a lot of headaches when it comes to integration and migration.