To make things worse, sometimes you have legacy ERP systems (e.g., in the higher education industry) that don’t have unique identifiers stored in a single field. Instead they use inferred keys derived from combinations of other fields.
In lieu of implementing a full MDM solution, one option to easily set up and manage these external identifiers can be to create just three components in Salesforce for each object: two fields and a workflow rule.
Auto External ID
The Auto External ID field is a Formula (Text) field that produces the string that represents the expected, globally unique external identifier. For example, the field could be a concatenation of two other values that produces something like “001154-900100203”.
Having this field also enables administrators to easily troubleshoot problems with the External ID value by comparing the expected identifier with the actual identifier.
{!ObjectLabel} External ID
The {!ObjectLabel} External ID field is a simple Text field configured to be a unique external identifier. The intent is that the Auto External ID value will always be stored in this field, so that DML operations via API’s can match on this field.
The {!ObjectLabel} part of this is simply a recommended labeling convention that helps your field look more like an out-of-the-box Salesforce field.
Set {!ObjectLabel} External ID
Finally, the Set {!ObjectLabel} External ID workflow rule should be configured to fire only when the Auto External ID and the actual External ID values do not match. This way, you avoid having a workflow rule that continuously edits a field blindly even when there is no need to update the field.
The workflow rule makes use of a simple field update that just sets the External ID field to the Auto External ID value.
And that’s all there is to this pattern! Now you can quickly create external identifier fields that are consistently derived and simple to troubleshoot.
