This pattern will help you write workflow rules that can be activated or deactivated based on Profile or Permission Set assigned to user.
Naming Pattern
| Component | Workflow Rule |
| Name | ObjectName_WFXXX_Word1Word2 Ex: Account_WF001_UpdateCity |
| Description | Free text Ex: Update the field City on each update. |
| Component | Workflow Task |
| Subject Label | Word1 Word2 Ex: Call Customer |
| Unique Name | ObjectName_Word1Word2 Ex: Account_CallCustomer |
| Component | Name & Unique Name |
| Workflow Email Alert | ObjectName_Word1Word2 Ex: Account_OwnerNotification |
| Field Update | ObjectName_Word1Word2 Ex: Account_UpdateCity |
| Outbound Message | ObjectName_Word1Word2 Ex: Account_UpdateExternalSystem |
Step 1
Create 2 Custom Permissions to handle activation and deactivation of the rule.
| Permission 1 | Permission 2 | |
| Name | BP_ALL_WF | BP_ACC_WF001 |
The first one will be used to deactivate all workflow rules when the Custom Permission is assigned Profile or Permission Set.
The second one will be used to deactivate only this workflow rule.
Step 2
We are going to write a simple workflow rule for the Account object based on a standard.
| Name | Account_WF001_POC |
| Description | This is a POC. |
| Evaluation Criteria | Choose the one that match your business case: – created – created, and every time it’s edited – created, and any time it’s edited to subsequently meet criteria |
| Rule Criteria | Formula evaluates to true |
| Formula | Below |
IF(
NOT($Permission.BP_ALL_WF) &&
NOT($Permission.BP_ACC_WF001),
true,
false
)
Now you can save your formula and play with some records and profiles / permission sets to see the magic.
The workflow should run if :
- The user has no global or local bypass assigned
- The result evaluates to true
Conclusion
There are other ways to design workflow rules, with custom hierarchical setting or fields on user, but it implies less flexibility and more maintenance. Here, we have not been able to handle Workflow Rule based on country attribute because Custom Metadata Type is not available. There are 3 solutions to this:
- One workflow rule per country with name finishing by the country code “Account_WF001_POC_FR”, we should avoid it as much as possible as it make the number of rule, complexity and maintenance grow.
- Rule that embeds some countries sharing the same actions: It will minimize the number of rules but it can reach limits depending on the number of country to test. It also can be complex and impact maintenance.
- Use Process Builder instead : We are using less and less Workflow in the benefits of Process Builder except for Outbound message that it’s not yet covered and some time depending on governor limits (ex: Number of flow execution per hour, limit that workflow don’t have). So, if Process Builder can solve your use case then go for it and don’t turn back to Workflow,
Hope you enjoy reading this article, see you soon for the next one ...
Salesforce Secure Development Library 