All Naming Conventions Are RFC 2119 and RFC 6919 compliant.

Triggers

A trigger MUST always be named after what Triggers the workflow, and not the actions. In all cases possible, the number of triggers per object SHOULD be limited - reading the existing trigger names allows using existing ones when possible. Knowing that all automations count towards Salesforce alloted CPU time per record, a consultant SHOULD consider how to limit the number of workflows in all cases.

1. All Worfklow Triggers MUST contain a Bypass Rule check.
• - If more Granularity is needed, a consultant MAY want to create a Hierarchical Custom Setting to implement the bypass.
• - This bypass can be added to the more common User-based bypass, but SHOULD NOT supplant it.
2. A Workflow Trigger SHALL always start by WF, followed by a number corresponding to the number of workflows on the triggering Object, followed by an underscore.

1. The WorkFlow Trigger name MUST try to explain in a concise manner what triggers the WF. Note that conciseness trumps clarity for this field.
2. All Workflows Trigger MUST have a description detailing how they are triggered.
3. Wherever possible, a Consultant SHOULD use operators over functions.

Examples

Object	WF Name	Description	WF Rule
Invoice	WF01_WhenInvoicePaid	This WF triggers when the invoice Status is set to "Paid". Triggered from another automation.	!$User.BypassWF__c && ISPICKVAL(Status__c, "Paid")
Invoice	WF02_CE_WhenStatusChanges	This WF triggers every time the Status of the invoice is changed.	!$User.BypassWF__c && ISCHANGED(Status__c)
Contact	WF01_C_IfStreetBlank	This WF triggers on creation if the street is Blank	!$User.BypassWF__c && ISBLANK(MailingStreet)

Field Updates

1. A Workflow Field Update MUST Start with FU, followed by a number corresponding to the number of field updates on the triggering Object.
2. A Workflow Field Update SHOULD contain the Object name, or an abbreviation thereof, in the Field Update Name. \\\\\\\\2*
3. A Workflow Field Update MUST be named after the field that it updates, and then the values it sets, in the most concise manner possible.
4. The Description of a Workflow Field UpdateSHOULD give precise information on what the field is set to.

Examples

Object	FU Name	Description
Contact	FU01_SetEmailOptOut	Sets the Email Opt Out checkbox to TRUE.
Invoice	FU02_SetFinalBillingStreet	Calculates the billing street based on if the client is billed alone, via an Agency, or via a mother company. Part of three updates that handle this adress.
Contact	FU03_CalculateFinalAmount	Uses current Tax settings and information to set the final amount

Email Alerts

1. A Workflow Email Alert MUST Start with EA, followed by a number corresponding to the number of email alerts on the triggering Object.

2. A Workflow Email Alert SHOULD contain the Object name, or an abbreviation thereof, in the Field Update Name. \\\\\\\\2*

3. A Workflow Email Alert's Unique Name and Description SHOULD contain the exact same information, except where a longer description is absolutely necessary. \\\\\\\\3*

4. A Workflow Email Alert SHOULD be named after the type of email it sends, or the reason the email is sent.

   Note that declaratively, the Name of the template used to send the email is always shown by default in Email Alert lists.

Examples

Object	EA Name	Description
Invoice	EA01_Inv_SendFirstPaymentReminder	EA01_Inv_SendFirstPaymentReminder.
Invoice	EA02_Inv_SendSecondPaymentReminder	SendSecondPaymentReminder
Contact	EA03_Con_SendBirthdayEmail	EA03_Con_SendBirthdayEmail

Workflow Tasks

1. A Workflow Task Unique Name MUST Start with TSK, followed by a number corresponding to the number of tasks on the triggering Object.

2. A Workflow Task Unique Name COULD contain the Object name, or an abbreviation thereof, in the Field Update Name. This is to avoid different conventions for Workflow Actions in general.

   Most information about tasks are displayed by default declaratively, and creating a task should rarely impact internal processes or external processes in such a manner that urgent debugging is required. As Users will in all cases never see the Unique Name of a Workflow Task, it is not needed nor recommended to norm them more than necessary.

Outbound Messages

1. An Outbound Message Name MUST Start with OM, followed by a number corresponding to the number of outbound mesages on the triggering Object.

2. An Outbound Message Name COULD contain the Object name, or an abbreviation thereof, in the Field Update Name. This is to avoid different conventions for Workflow Actions in general.

3. An Outbound Message MUST be named after the Service that it send information to, and then information it sends in the most concise manner possible.

4. The Description of An Outbound Message SHOULD give precise information on why the Outbound Message is created.

5. Listing the fields sent by the Outbound Message is NOT RECOMMENDED.

Examples

Object	EA Name	Description
Invoice	OM01_Inv_SendBasicInfo	Send the invoice header to the client software.
Invoice	OM02_Inv_SendStatusPaid	Sends a flag that the invoice was paid to the client software.
Contact	OM01_SendContactInfo	Sends most contact information to the internal Directory.

*1 This is also the default Salesforce setting.* *2 While Field Updates are segregated by Object when viewed through an IDE or through code, the UI offers no such ease of use. If this is not done, a consultant WOULD PROBABLY create list views for field updates per Object.* *3 Email Alert's Unique Names are generated from the Description by default in Salesforce. As Email Alerts can only send emails, this convention describes a less exhaustive solution than could be, at the profit of speed while creating Email Alerts declaratively.*