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. 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) Workflow Field Updates 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. 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.1 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 Update SHOULD 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 address. Contact FU03_CalculateFinalAmount Uses current Tax settings and information to set the final amount 1 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.Workflow Email Alerts 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 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. A Workflow Email Alert's Unique Name and Description SHOULD contain the exact same information, except where a longer description is absolutely necessary.1 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 1 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.Workflow Tasks 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. 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. Workflow Outbound Messages 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.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 An Outbound Message Name MUST Start with OM, followed by a number corresponding to the number of outbound messages 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. 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.