Advanced Object Naming Strategies in Salesforce

Object names are the primary means of record identification in Salesforce. Salesforce offers two primary approaches to object naming: auto-generated names and user-provided names. 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.

In some cases, object names need to reflect information from other fields. For example, an opportunity name might incorporate details like quantities, product codes, SKUs, or customer types. “A name such as ’10 widgets for Acme Corp’ provides context and enables users to immediately understand what they are looking at.

This post explores advanced strategies for object naming that go beyond Salesforce’s out-of-the-box capabilities.

Object Naming Example: A Subscription Service

Subscription services, such as hosted databases, bare-metal servers, SaaS applications, or broadband Internet, often require a reference number for billing and support purposes. These identifiers can range from a simple ID to a more structured generated name, such as “SRV-000001” in Salesforce.

However, in most cases, the name carries additional information, such as the product (linked to a product lookup or record type), customer type, region, initial term start date, or other relevant details. This extra context helps back-office teams quickly identify the subscription service without digging into the details, significantly improving their efficiency.

For example, a naming convention like “B-INTERNET-100-000001” might represent the following:

• B-INTERNET: Business Internet service (product code),
• 100: 100 Mbps speed,
• 000001: Unique identifier for the subscription.

This type of structured naming scheme cannot be achieved with Salesforce’s standard auto-naming, requiring the use of regular object names supplemented by custom coding.

The First Step: Ensuring Name Uniqueness

Auto-naming in Salesforce inherently guarantees unique names. However, this is not the case for user-provided names, which can lead to duplication issues. In the subscription service example, ensuring uniqueness is critical to avoid confusion in support or billing processes.

Therefore, the first step in the implementation is to enforce name uniqueness, ensuring that each record can be reliably identified.

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)
)

Object Naming: Strategies and Implementation Options

Once ensuring name uniqueness is out of the way, the following options are available for name generation:

Generating Unique Name Parts

Even when generating names automatically (e.g., via a trigger), a unique component is most likely required to ensure name uniqueness.

For example, in the “B-INTERNET-100-000001” example above, multiple instances of the “B-INTERNET-100” product may exist, so a unique suffix is necessary.

There are two primary methods for achieving this:

• AutoNumber Field: Add an AutoNumber field directly to the object and incorporate it into the trigger code.
• Custom Setting Variable: Use a Custom Setting variable to track the current number, handling increments programmatically in the trigger code.

While the Custom Setting approach is more complex to implement, it offers greater control over numbering. For instance, the current value can be manually adjusted as needed. This method is commonly employed in Nextian products.

Backup Considerations

One significant limitation of auto-generated names is that they may not restore correctly from backups. If an object is deleted and later recovered, a new name is generated instead of retaining the original one. For instance, an object named OBJ-0001 might be restored as OBJ-0052, potentially causing confusion or inconsistencies. This limitation should be considered when selecting an object naming strategy.

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.

An Alternate Approach: User-Initiated, Manual Name Standardization

In some scenarios, strict naming rules may not be practical. For instance, consider a CRM opportunity where the sales representative initially knows only the account details but lacks information about products, quantities, or the number of sites needed for a complete name.

In such cases, it’s often better to allow users the flexibility to enter any name initially. A dedicated action button, such as Standardize Name” can then be used to update the name based on a predefined convention once the required details are available.

For example, At Nextian, we use this approach for standardizing service address names to conform 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 has extensive experience in implementing complex Salesforce customizations with Apex and Lightning, helping our clients unlock the full potential of their Salesforce.

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