Workflow Triggers
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