# Workflow Conventions Naming and structural conventions related to workflows # 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. 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. #### ExamplesObject | 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)` |
**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.**
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.1 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 Update ***SHOULD*** give precise information on what the field is set to. #### ExamplesObject | 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 address. |
Contact | FU03\_CalculateFinalAmount | Uses current Tax settings and information to set the final amount |
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. **Email Alerts are NOT part of the Workflow Rule deprecation plan- you can and should continue to configure and use Email Alerts. Flows can reference and execute these 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. 3. A Workflow Email Alert's Unique Name and Description ***SHOULD*** contain the exact same information, except where a longer description is absolutely necessary.1 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. #### ExamplesObject | EA Name | Description |
---|---|---|
Invoice | EA01\_Inv\_SendFirstPaymentReminder | EA01\_Inv\_SendFirstPaymentReminder. |
Invoice | EA02\_Inv\_SendSecondPaymentReminder | SendSecondPaymentReminder |
Contact | EA03\_Con\_SendBirthdayEmail | EA03\_Con\_SendBirthdayEmail |
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.
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. # Workflow Outbound MessagesWorkflow 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. **Outbound Messages are NOT part of the Workflow Rule deprecation plan- you can and should continue to configure and use Outbound Messages when appropriate. Flows can reference and execute these Outbound Messages**
1. An Outbound Message Name ***MUST*** Start with `OM`, followed by a number corresponding to the number of outbound messages 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***. #### ExamplesObject | 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. |