Advanced object naming strategies in Salesforce

Object names are the primary means of record identification in the Salesforce user interface including details, list views, reports, lookup fields and others.

Salesforce object names can be either user-provided or auto-generated. Auto-generated names are unique, but quite simple — just a sequence number with optional prefix/suffix (e.g., CNTRCT-012412). User-provided names can be complex (anything a user wants!) but are not unique.

Sometimes however, object name needs to be based on other fields — e.g., opportunity name may be based on quantities, product code, SKU, customer type, e.g., “10 widgets for Acme Corp”.

Object naming example: a subscription service

Subscription services usually require a reference number for billing and support.

It can be as simple as a single id or (in case of Salesforce), a generated name like SRV-000001, but usually it carries additional information such as product (which may be a lookup to the product or a record type), customer type, region, initial term start date, etc. This additional information tells back-office teams what the subscription service is, without having to look into details, increasing their efficiency.

For example, B-INTERNET-100-0000001 may indicate product code (business Internet service), 100mpbps speed and 000001 would be the unique part.

Ensuring name uniqueness

While there is no ‘unique name’ option in the Salesforce user interface, it can be implemented using VLOOKUP within a validation rule. For instance, to ensure that Contract__c object has unique name, the validation rule could look as follows:

(
   ISCHANGED(Name) && 
   Name = VLOOKUP($ObjectType.Contract__c.Fields.Name, $ObjectType.Contract__c.Fields.Name, Name)
) 
||
(
   ISNEW() && 
   Name = VLOOKUP($ObjectType.Contract__c.Fields.Name, $ObjectType.Contract__c.Fields.Name, Name)
)

Implementation options for object naming in Salesforce

The following table summarizes options for object name implementation:

Option	Pros	Cons
User-provided	Easy to configure — standard out-of-the box functionality Recoverable via backup	Users must provide names Names are not unique Names can change (are user-editable)
User-provided with ensured uniqueness	Names are guaranteed to be unique Recoverable via backup	Users must provide names Names can change (are user-editable)
User-provided with ensured uniqueness and additional validation	Names are guaranteed to be unique Names are guaranteed to follow a required syntax Recoverable via backup	Users must provide names — high likelihood of mistakes Names can change (are user-editable)
Generated name (e.g., SRV-000001)	Easy to configure — standard out-of-the box functionality Unique, consistent names	Simple syntax Not easily recoverable via backup (see notes below) Good choice for simple names but not ones that hold an important reference or shared with customers (see notes on backup below)
Overwriting standard name with a trigger or workflow	Full control over naming process Can be also applied to standard objects such as opportunities, etc.	Requires some APEX or workflow programming effort Name cannot be made read-only on layouts so users will have to enter a value that will be overwritten Good choice for complex names, works great with backup and data cleanup tools
Formula derived or trigger generated fabricated name	Full control over naming process	Not shown as object link in lookup fields, reports, etc. Good choice for secondary identifiers (e.g., adding Opportunity Code/Reference to the standard opportunity object)

Generating unique name parts

Even when generating names via a trigger, a generated part is most likely required to ensure name uniqueness.

For instance, in the B-INTERNET-100-000001 example above, since there may be multiple B-INTERNET-100 products sold, a unique suffix must be provided.

There are two ways to of achieving this:

Add AutoNumber field directly on an object and use it in the trigger code
Add a Custom Setting variable to keep track of current number and use it and handle increments in the trigger code

The latter solution is more cumbersome to implement, but gives more control over numbering, i.e., the current value can be easily set.

Backup considerations

One problem with auto-generated names is that they are not restoring correctly from backups. If an object is deleted and recovered, the new name will be generated anew, e.g., OBJ-0001 could become (for example) OBJ-0052.

Tip

At Nextian we recommend using standard auto-generated names only for objects that attribute no special meaning to names, such as junction objects.

A different approach: user-initiated, manual name standardization

There are situations where naming rules are not strict. Let’s consider a CRM opportunity: initially, the rep may know the account but have limited information about product, quantities, number of sites, etc. that are required for the full name.

In those cases, it’s best to give users freedom to enter any name they want, but to add an action button to ‘standardize’ the name according to a pre-defined convention.

For example, at Nextian we take this approach to change service address names to adhere to the Google address format:

Conclusions

In some cases, out-of-the box Salesforce object naming options (user-provided or auto-generated) may not be sufficient. These limitations however can be overcome with APEX programming, validation rules, actions or their combination.

Nextian is a vendor of Quote-to-Cash (QTC) software for cloud and communications helping providers accelerate growth and increase customer lifetime value.

Contact us today to find out how we can help you!