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.
- All Worfklow Triggers MUST contain a Bypass Rule check.
- - If more Granularity is needed, a consultant MAY want to create a
Hierarchical Custom Settingto implement the bypass.
- - This bypass can be added to the more common User-based bypass, but SHOULD NOT supplant it.
WF, followed by a number corresponding to the number of workflows on the triggering Object, followed by an underscore.
- The WorkFlow Trigger name MUST try to explain in a concise manner what triggers the WF. Note that conciseness trumps clarity for this field.
- All Workflows Trigger MUST have a description detailing how they are triggered.
- Wherever possible, a Consultant SHOULD use operators over functions.
|Object||WF Name||Description||WF Rule|
|Invoice||WF01_WhenInvoicePaid||This WF triggers when the invoice Status is set to "Paid". Triggered from another automation.|
|Invoice||WF02_CE_WhenStatusChanges||This WF triggers every time the Status of the invoice is changed.|
|Contact||WF01_C_IfStreetBlank||This WF triggers on creation if the street is Blank|
- A Workflow Field Update MUST Start with
FU, followed by a number corresponding to the number of field updates on the triggering Object.
- A Workflow Field Update SHOULD contain the Object name, or an abbreviation thereof, in the Field Update Name. \\\\\\\\2*
- 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.
- The Description of a Workflow Field UpdateSHOULD give precise information on what the field is set to.
|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|
A Workflow Email Alert MUST Start with
EA, followed by a number corresponding to the number of email alerts on the triggering Object.
A Workflow Email Alert SHOULD contain the Object name, or an abbreviation thereof, in the Field Update Name. \\\\\\\\2*
A Workflow Email Alert's Unique Name and Description SHOULD contain the exact same information, except where a longer description is absolutely necessary. \\\\\\\\3*
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.
A Workflow Task Unique Name MUST Start with
TSK, followed by a number corresponding to the number of tasks on the triggering Object.
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.
An Outbound Message Name MUST Start with
OM, followed by a number corresponding to the number of outbound mesages on the triggering Object.
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.
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.
The Description of An Outbound Message SHOULD give precise information on why the Outbound Message is created.
Listing the fields sent by the Outbound Message is NOT RECOMMENDED.
|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.*