I’ve not worked with workflow rules (WFRs) for years, ever since processes and flows were introduced. I stumbled on this benefit of WFR while migrating said WFR to a record triggered flow. I converted a time based WFR to a scheduled path record triggered flow. Easy peasy. But, when I went to test it, my cool new flow faulted because it hit a validation rule. What?! All I did was convert the simple WFR to a simple flow. How could it have failed? How does the WFR work in Production and not hit on the validation rule too?

Apparently, when WFRs execute, they bypass validation rules. However, processes and flows do not. Bummer.

While there are ways to work around this, such as set a processing checkbox before the update and then uncheck the processes checkbox after or assign a session based permission set to the user before, #Flownatic Parker Edelmann has a really cool solution to combat your automation validation rule battle woes, which he presented in an episode of Automation Hour.

Parker’s brilliant solution involves the below:

• Create a date/time field to hold the automation date/time – call it Automation Date/Time.
• Create a checkbox field – call it Is Automation Bypassed? – that sets to true if the automation date/time is greater than now minus 5 seconds.
• In the offending validation rule, add a criteria that the checkbox is set to false – && Is_Automation_Bypassed__c = false.
• In your automation (process or flow), add a step to set the automation date/time field for the record to now, which set the checkbox filed to true – Is_Automation_Bypassed__c Equals Now().

****If you are working on moving WFRs or processes to flows, especially to before save record triggered flows, please be mindful of the order of execution, especially if you have automation on the same object using different methods – triggers, processes, workflow rules, etc. Do a thorough regression test of the new flow against existing automation solutions to ensure record changes are happening in the order they are expected. If you have test classes on the same object, I’d recommend running those to ensure they continue to run successfully after your new flow replaces the legacy automation solution.

This blog post is inspired by Parker’s solution…

Here are a few lessons learned from implementing this use case:

• Set up a date/time and checkbox formula to calculate the automation bypass date/time and whether the automation is bypassed, respectively.
• Set the automation bypass date/time in your flow and/or process and bypass that validation rule.

Business Use Case:  Addison Dogster is the system administrator at Universal Containers. She is working to address tech debt by moving existing workflow rules to flow. Her next WFR updates the account name with the current date/time when there is an update to the account.  

Solution: Addison thought that this is an easy solution. Create a record triggered before save flow to update the account name to account name – <date/time now> instead. When she went to test the solution, she found that the flow did not implement because of an existing validation rule which does not allow the account name to be changed. But how does the WFR work and not run into the same problem? She then learns that a workflow rule has an extra super power where it can bypasses validation rules. Processes and flows are mere mortals in that regard.

She googled and found an Automation Hour video where Parker Edelmann has a cool solution to combat the validation rule situation.

Here is a demo of the existing validation rule, the flow and the solution for the flow to bypass the validation rule.

View Image Full Screen

Highlighted Steps: 

1.Create a custom date/time field to hold the automation date/time – call it Automation Date/Time. This field does not need to display on the page layout as it is used for processing purposes only.

Best practice tip: Provide a description so you and other/future admins know what this custom field is used for.

2. Create a custom checkbox field – call it Is Automation Bypassed? – that sets to true if the automation date/time is greater than now minus 5 seconds. This field does not need to display on the page layout as it is used for processing purposes only.

AutomationBypassDateTime__c > NOW() – 0.00005787037 /*Five Seconds*/

Best practice tip: Provide a description so you and other/future admins know what this custom field is used for.

3. Update the validation rule you want the process or flow to bypass by adding a check for the Is Automation Bypassed? field is set to false. If IsAutomationBypassed = true (which your process or flow will update for the formula checkbox to evaluate to true), then the validation rule will be bypassed.

&& IsAutomationBypassed__c = false

4. In your process or flow, set the AutomationBypassDateTime__c to now(). This will allow the IsAutomationBypassed__c to evaluate to true, bypassing the validation rule.

Deployment Notes/Tips:

• The custom fields, FLS, validation rule and record triggered flow and/or process can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
• You will find the flow and/or process in a change set under the Flow Definition component type.
• Activate the flow post deployment as flows and/or processes deploy inactive in Production, unless you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must cover at least 75% of the total number of active processes and active autolaunched flows in your org or you can select 0%, which will run the apex classes not related to your flow.