# General Conventions

All Naming Conventions Are [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) and [RFC 6919](https://tools.ietf.org/html/rfc6919) compliant.

1. All field API names **MUST** be written in English, even when the label is in another language.
2. All field API names **MUST** be written in PascalCase.
3. Fields **SHOULD NOT** contain an underscore in the fields name, except where explicitly defined otherwise in these conventions.
4. Fields generally **MUST (but you probably won't)** contain a description.
5. In all cases where the entire purpose of the field is not evident by reading the name, the field **MUST** contain a description.
6. If the purpose of the field is ambiguous, the field **MUST** contain a help text. In cases where the purpose is clear, the help text **COULD** also be defined for clarity's sake.
7. Field API names should respect the following prefixes and suffixes.<sup>2</sup> Prefixes and Suffixes **SHALL NOT** be prepended by an underscore.

<table id="bkmrk-field-type-prefix-su" style="height: 296px;" width="893"><tbody><tr style="height: 29px;"><th style="height: 29px; width: 433.383px;">Field Type</th><th style="height: 29px; width: 270.617px;">Prefix</th><th style="height: 29px; width: 105.2px;">Suffix</th></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">MasterDetail</td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Ref`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Lookup</td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Ref`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Formula</td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Auto`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Rollup Summary</td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Auto`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Filled by automation (APEX)<sup>1</sup></td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Trig`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Picklist or Multipicklist</td><td style="height: 29px; width: 270.617px;">  
</td><td style="height: 29px; width: 105.2px;">`Pick`</td></tr><tr style="height: 29px;"><td style="height: 29px; width: 433.383px;">Boolean</td><td style="height: 29px; width: 270.617px;">`Is` or `IsCan`<sup>3</sup></td><td style="height: 29px; width: 105.2px;">  
</td></tr></tbody></table>

*<sup>1</sup> Workflows, Process Builders and Flows are not included in this logic because these automations either allow field name modifications with no error, or can be modified by an administrator. If fields are created for the sole purpose of being filled by automation (e.g. fields that will be used in roll-up summaries), a consultant **WOULD PROBABLY** use the Trig suffix anyway, to indicate that users cannot set the data themselves.*

*<sup>2</sup> While norms for other field types were considered, e.g. to make sure number, currency and percentage fields were easily recognizable, they were discarded as being too restrictive for an admin. Fixing type mismatches in this case is easily solved by casting the value to the correct type using either `TEXT()` or `VALUE()` functions.*

*<sup>3</sup>`IsCan` replaces "Can", **e.g.** `CanActivateContract` becomes `IsCanActivateContract`. This is to enable searching for all checkboxes on a page with a single query.*