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.

Auto-naming Records in Salesforce

Usually on Sales Cloud implementations, business users will want to know, "What should we name our opportunities in Salesforce?" Great question, and a better follow-up, "How can we get our users to follow this convention?"

The Best Practices for Sales Managers still recommends, "Opportunity name reflects what the deal entails. ... it will help to simply adopt a consistent opportunity naming convention." While there are many ways to automatically name a record in Salesforce, each having different pros and cons, the method described below should offer the greatest flexibility and ease of maintenance for administrator.

When implemented for Opportunities or for any object, business users will be able to:

• Create the record with a custom name; or
• Create the record with an automatically generated name matching the naming convention

Furthermore, business users will be able to:

• Change the record name later, regardless of how the name was generated
• Easily revert to the automatically generated name

One Rule. One Field. One Update.

All that's needed are three components: a formula field, a workflow rule and one field update.

For simplicity and consistency across objects, the formula field can be called Auto Name (AutoName__c), and its text output should be exactly what you would expect to see based on your naming convention. What's nice about using this formula field is that you can visually see what the result would be if you were to apply auto-naming to existing records.

Next, create a workflow rule called Set Opportunity Name, with a simple formula determining the entry criteria: LEN( Name ) <= 1. The idea is that if the user types in a single character in for the record name, which is a required field, Salesforce assumes that the user wants to apply the auto name.

Finally, add a quick field update called Opportunity Name to the workflow rule. All this field update needs to do is to set the Opportunity Name field to be exactly the same as Auto Name, using a formula.

With these three components, you can help your users make the most of auto-naming in Salesforce while still giving them the flexibility of later customization.

Secret Search Layout Feature in Salesforce1

If you open an object tab in Salesforce1, you'll probably see something very similar to the screenshot below. A search box. Available list views. Recent items with... a teaser field on each item?

S1 has an interesting feature that enables users to see one field on each recent item on an object tab's home page. This feature appears to be undocumented in either the first version of the Salesforce1 App Developer Guide, or the "Customizing Search Layouts" Help page.

To configure which field appears here, modify the Columns Displayed for the Search Results Search Layout on the object. This is counter-intuitive, because in the browser app the columns displayed for recent items is controlled through the {!ObjectLabel} Tab Search Layout.

Have you found any other hidden configuration options for S1? Please share them in the comments!

P.S. Thank you to Brian Casey for tipping me off to this interesting discovery!

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.