Controlling the creation of fields is necessary to avoid adding unnecessary new fields in Salesforce. Without appropriate field creation governance, there is a risk of producing an application with a complex data structure that provides a poor user experience.
This issue can often be observed due to the ease of creating new custom fields, however, there are other causes such as:
- Configuring spontaneous responses to end-user field creation requests without gathering full requirements
- Lack of specification or understanding of reporting requirements for field usage
- Creation of fields that are too specific for common uses, thus driving the need to create ever more fields
- Lack of knowledge or awareness of existing fields that could be used rather than creating from new
As the number of unnecessary fields increase, users will find it ever more difficult to enter the correct data into the correct fields. Therefore, the amount of entered data is reduced along with users' satisfaction because the application requires more effort to work with. It is all too easy for your users to become dissatisfied and this can lead to less usage overall and hence poor data quality due to a lack of user participation.
Create new fields with care because as each new custom field is added, your application structure increases in complexity. As the system administrator, you are responsible for knowing which fields are used, where they appear on Page Layouts, and which fields are required for reporting.
If the benefits and long-term use for a new field cannot be easily understood, it is unlikely to be of much use. One method to help determine its use is to consider where and how the proposed new field would be used in a report. If it is never going to be reported, it may be worth querying its purpose and value. The following considerations can be made when creating new fields:
Try to make your field names more generic so that they can serve multiple purposes. In some situations, different business units share objects but track different information. Although they may have different requirements, they can often share fields. Here you need to be proactive, forward-thinking, and reach out to the business and propose fields that can be used across multiple business units.
Often there are unnecessary date fields used to track milestones or data processing dates. With native field history tracking, these milestones can be tracked and reported without the need to always create new fields.
Create milestone objects and related lists to avoid hard-coding date fields on a record. For example, avoid creating fields to track dated historical financial information within an object. Here you may have to create redundant fields for each year. For example, 2011 Budgets, 2012 Budgets, and so on. Instead, create an Financials object with one set of fields and a corresponding date field where you can create a new record each year. This can result in fewer fields and far better display and reporting.