Skip to main content

Grouping fields

  1. If the organization is home to multiple services, the field API name SHOULD be prepended with the name of the service that required the field, followed by an underscore.
    • This MUST NOT be the case if there is only one service using the object.
  2. If several services use the field, or the field was originally required by a service before being used by others: the field API name MUST (but you probably won't) be prepended with the name of the service that is responsible for the user story that lead to the field creation, followed by an underscore. The Description of the field MUST indicate which services use the field.1
  3. In the case the field is use differently by different services, the Description of the field MUST contain a summary description of each use.
  4. If a field is created to host a value for technical reasons, but is not or should not be displayed to the users, the API name MUST be prefixed with TECH and an underscore.
  5. If more than 50 fields are created on an object, a consultant SHOULD consider using prefixes to group fields in the same manner as technical fields, in the format of $Groupname followed by an underscore.

Examples

Object Field type Comment Field Label Field API Name Field Description
Case Lookup Looks up to Account Service Provider ServiceProviderRef__c Links the case to the Service Provider who will conduct the task at the client's.
Account Formula Made for the Accounting department only Solvability Accounting_SolvabilityAuto__c Calculates solvability based on revenue and expenses. Sensitive data, should not be shared.
Contact Checkbox   Sponsored ? IsSponsored__c Checked if the contact was sponsored into the program by another client.

 

1 While modifying API names post-deployment is notoriously complicated, making sure that field are properly recognizable is better in the long term than avoiding a maintenance during a project. Such modifications SHOULD be taken into account while doing estimations.

No Comments
Back to top