Workflow Triggers
Workflow Rules (along with Process Builders) are now on a deprecation / End-of-Life plan. Existing Workflow Rules will continue to operate for the foreseeable future, but in the near future (Winter 23) Salesforce will begin to prevent creating new Workflow Rules. Establish a plan to migrate to Flows, and create any new automation using Flow Builder.
These naming convention best practices will remain in place for reference purposes so long as Workflow Rules may exist in a Salesforce org
A workflow 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 allotted CPU time per record, a consultant SHOULD consider how to limit the number of workflows in all cases.
- All Workflow Triggers MUST contain a Bypass Rule check.
- 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. - 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.
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) |
No Comments