Updated – 2014-11-18
This post follows on from my last post on Custom Settings and provides coverage of the wider set of naming conventions I apply across the various component types of the declarative build environment. The list isn’t exhaustive or necessarily better than any other set of standards. Having a set of conventions applied consistently across the build is key, the specifics of those conventions can be subjective. A key principle applied is that of consistency with established standard conventions wherever possible. For example, standard objects and fields don’t have underscores in the API names and follow simple patterns in terms of naming, there’s no good reason to deviate from this for custom objects and fields. Naming conventions shouldn’t be considered an area for creative thinking, instead creative energy should be focused on the functional and technical design, the conventions applied should be mundane and predictable.
Convention A – Custom Object
[Object name]. Singular, Pascal Case (upper camel case) and no underscores.
e.g. Data Source -> DataSource__c
Consistent use of the default naming style, i.e. with underscores is acceptable also. it can be difficult to avoid this approach in a team environment.
e.g. Data Source -> Data_Source__c
Note – the Description attribute for Custom Objects must always be populated appropriately. A self describing configuration is key to future maintenance.
Convention B – Custom Field
[Field name]. Pascal Case (upper camel case) and no underscores.
e.g. Date of Birth -> DateOfBirth__c
Consistent use of the default naming style, i.e. with underscores is acceptable also. it can be difficult to avoid this approach in a team environment.
e.g. Date of Birth -> Date_Of_Birth__c
In the scenario where an implementation is comprised of distinct functional domains, with custom fields relating specifically (and exclusively) to one single domain, the following convention should be applied.
Each functional domain has a defined field name Prefix. e.g. HR, FINANCE, SALES etc.
Fields exclusive to one domain have their API name prefixed with the domain prefix.
e.g. Payroll Number -> FINANCE_PayrollNumber__c
e.g. Industry Segment -> SALES_IndustrySegment__c
This convention allows a logical structure to be applied in isolating fields specific to a single functional domain.
Note – the Description attribute for Custom Fields must always be populated appropriately. A self describing configuration is key to future maintenance.
Note – the Help Text attribute for Custom Fields must always be populated appropriately. Inline user assistance can improve the end user experience greatly and reduce ongoing support.
Convention C – Child Relationships
Singular, Pascal Case (upper camel case) and no underscores.
e.g. Account->AccountMetrics__c relationship = Account.AccountMetrics__r
Convention D – Page Layout
[[Function] | [Object]] Layout
e.g. Pricing Case Layout
e.g. Pricing Case Close Layout
Convention E – Custom Setting
Custom Setting Label – Pluralised in all cases (e.g. Data Sources). No “Setting[s]” suffix.
API Name – List Settings
– [Data entity that each list entry represents]ListSetting__c
Each record represents an individual entry and as such singular naming is applied, as per objects.
e.g. Analytic Views – AnalyticViewListSetting__c
e.g. Data Sources – DataSourceListSetting__c
API Name – Hierarchy Settings
– [Function of the settings]Settings__c
Each record represents the same set of settings applied at different levels. In concept this differs from objects and list settings, the plural naming reflects this.
e.g. Org Behaviour Settings – OrgBehaviourSettings__c
e.g. My App Settings – MyApplicationSettings__c
Convention F – Workflow Rule
Always separate the condition from the outcome when configuring workflow. The Workflow Rule is the condition, the associated Actions are the outcome. In many cases the 2 become entwined resulting in duplicated rules, or rules with actions unrelated to the stated purpose of the rule. A clear set of rules related to conditions promotes re-use.
[Object]: [Criteria Description i.e. Condition]
Convention G – Workflow Action
Field Update –
[Object]: Set [Field] to [Value]
Email Alert –
[Object]: Send [Template short description]
Task –
[Object]: [Task Subject]
Convention H – Sharing Rule
OBS: [Object] [From selection] to [To selection]
CBS: [Object] [Criteria] to [To selection]
Convention I – Custom Report Type
[Primary Object] with [Child object]s [and [Grandchild object]s]
Convention J – Custom Label
Define sensible categories for the labels. e.g. UI Button Label, UI Text, UI Error Message etc.
Name = [Category with underscores]_[Value with underscores] e.g. UI_Button_Label_Proceed
Category = [Category with underscores] e.g. UI_Button_Label
ShortDescription = [Category] [Value] e.g. UI Button Label Proceed
Value = [Value] e.g. Proceed
Convention K – Validation Rule
Single field :
[Field Label] [rule applied]
Mailing City Is Required
Start Date Must Be a Weekday
Multiple fields :
[Field grouping term] [rule applied]
Billing Address Must Be Complete
Cross object :
[Object Name] [Field Label] [rule applied]
Opportunity Stage Is Closed No Edit Of Opportunity Products
Convention L – Publisher Action
[Verb] [Noun]
New Invoice
Update Order
Alert Executive Team
Convention M – User Profile
[[Job Function] | [Department] | [Company]] [[User] | [System Administrator]]
Accounts Payable User
Marketing Executive User
Acme System Administrator
Convention N – Permission Set
Single Permissions :
Name must match the permission assigned.
Case Feed
Manage Dashboards
Manage Public List Views
Simple Combined Permissions :
[Verb] [Noun]
Manage Invoices
Combined Permissions :
[Feature Area Descriptor] [User Type]
Work.com Administrator
CloudInvoices User
Knowledge Contributor
Convention O – Public Group
[Grouping term] [[Users] | [Members]]
EU Users
Sales Users
HR Users
Project A Members
Convention P – Reports and Dashboard Folders
[Grouping term] Reports (adhoc reports related to a specific department, team, project etc.)
[Grouping term] Dashboard Reports (best practice to isolate dashboard reports in clear location)
[Grouping term] Dashboards
Finance Reports
HR Dashboards
HR Dashboard Reports
Note – the [Report Description] attribute for Reports must always be populated appropriately. A self describing configuration is key to future maintenance.