Richard E. Moore Music and Sound Design

Adding Custom Fields to Salesforce is part art, part science. While we have great flexibility, we also need to be disciplined and cautious – when should we add a new custom field, and when should we use an existing custom field? We have a limit on how many custom fields we can add, and having too many custom fields will cause you a headache for maintenance and data categorization. In fact, having too many custom fields on an object is a very large red flag for a poorly architected solution. This typically indicates not only poorly designed fields, but also scattered data, and likely information being kept at the wrong level – there’s likely some fields there that should truly belong on a related object.

Long story short: Using an existing field is always preferable to creating a new field.

Does a similar field exist on the object?

Can we reuse an existing field?

Often we will get a request from the business to create a custom field that closely resembles an existing field. Too often, a Salesforce shop will simply take that request and implement it directly. Keep in mind that the business users are not the experts in Salesforce architecture – that’s our job as Developers, Admins, and Architects!

Example:

Customer requests to add a new field to Account called “BusinessAccountFocus__c“, which will capture the following values: “Individual”, “Commercial”, “Retail”. These values should appear for Accounts with a Record Type of “Business”. However, we have an existing field called “Focus__c“, which has the values “Individual”, “Family”, “International”. This field is used for Accounts with a record type of “Research Institution”.

In this case we can most likely use the existing field, adding picklist options and restricting the values available by record type. As long as we are not going to capture disparate data in both fields at the same time, we should prefer the more generic field “Focus__c“. Also note that we shouldn’t have a field on an object that is restricted to a given type. In this case, even if we decide that we must have two different fields, we should not call it “BusinessAccountFocus__c” but maybe something more accurate, like “MarketFocus__c“, or even “Audience__c“.

Is this field properly named / categorized for future reuse?

We often get requests from business to add fields that are much too specific. Below are some good and bad examples:

• 2023_Preferences__c – this is an example of a bad field name because it will obviously only be a valid / appropriate field name for one year. Prefer something like Preferences__c.
• BusinessAccount_Directions__c – We often get requests like this, because business thinks “we are capturing new data for Business Account records!”. If there is not an existing field for this, we should call this simply Directions__c so that we can POSSIBLY use this field for non-Business Account records.

Question: But what if we will NEVER use this field for non-Business Account records?
Answer: Never say never! Even if that is the case, it is against best practice to have such a specific name on a field. That would be akin to creating a Custom Object called “Accounts_In_Virginia__c” in addition to the Account Standard Object. There may be a valid reason to identify such records, but that is not the appropriate way to do so!

Question: But we already have a field called “2023_Flavors__c”, so it makes sense to have “2024_Flavors__c”, right?!
Answer: No it doesn’t 🙂. The new field should be “Flavors__c” and the old field can slowly expire. We should explore migrating data from the old field to the new, so the old field can be deleted.

Question: But we already have a field called “NW_TemplateText__c”, so it makes sense to have “SW_TemplateText__c”, right?!
Answer: No it doesn’t 🙂. The new field should be “TemplateText__c” and the old field can slowly expire. We should explore migrating data from the old field to the new, so the old field can be deleted.

Please also make sure to reference your team’s Naming Conventions for related information!

The items above are intended to be guidelines only. As ever, consult with the team (and your friendly neighborhood architect) if you are having any issues or confusion! It’s up to all of us to keep our Orgs in good working order!