**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. 1. All Workflow Triggers ***MUST*** contain a Bypass Rule check. 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. 3. The Workflow Trigger name ***MUST*** try to explain in a concise manner what triggers the WF. Note that conciseness trumps clarity for this field. 4. All Workflows Trigger ***MUST*** have a description detailing how they are triggered. 5. 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)` |