Auto External ID for Multi-Partner Integrations

Some companies need to integrate with multiple partner systems, each having its own set of unique identifiers. When you only have one or two of these external identifiers to manage, you can get away with setting up system-specific External ID fields. But happens when you trying to integrate with more than two such systems?

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.

Contact Age Formula Field

Salesforce users may want to see the current age of a contact, without resorting to mental date arithmetic based on the standard Birthdate field. Since this example is not listed (at the time of writing) in the Sample Contact Management Formulas, the formula below should do the trick for anyone looking to add this info to Salesforce.

Listing Required Fields for an Object in Salesforce Using Apex Code

Sometimes it's desirable or necessary to get a list of all required fields for a particular Salesforce object, especially for subsequent processing in Apex. Instead of hard-coding this list, which is not sustainable or maintainable long-term, a better approach is to use Salesforce field describe results and the isNillable() method.

Below is sample code that demonstrates this approach, code that can be adapted for any standard or custom object.