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 |
|
|
User-provided with ensured uniqueness |
|
|
User-provided with ensured uniqueness and additional validation |
|
|
Generated name (e.g., SRV-000001) |
|
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 |
|
Good choice for complex names, works great with backup and data cleanup tools |
Formula derived or trigger generated fabricated name |
|
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!