Jennifer Lee and Parker Edelmann on "How I Solved It"

How I Solved It: Bypass Validation Rules in Flows

By

Welcome to another post in the “How I Solved It” series. In this series, we do a deep dive into a specific business problem and share how one #AwesomeAdmin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Parker Edelmann used a creative workaround to bypass validation rules in flows.


Key business problem

Ever get Flow error emails as a result of your flow competing with a validation rule? Or maybe you’re planning to roll out new validation rules and want to proactively avoid such a scenario? Are there simply some actions that only a flow should be able to do, and you need to block your users from performing the exact same action? These sorts of clashes are frustrating to work around as an admin—and even more frustrating to users when they’ve done everything right but can’t continue with their job due to a system error.

How I solved it

The fix is quite simple, although there are a lot of options that deserve consideration but are less than optimal or don’t work. Let’s go over a few.

  • Check a box on the record. On paper, this should work, but in practice, if we don’t uncheck that box, the record will be perpetually bypassed. Yikes! We only want the flow to bypass our rules, not everything else. If we simply try to uncheck the box later on, we’ll probably get an error, so we’re back to the drawing board.
  • Permission set. We could assign a permission set to the user in question temporarily and check if the user has it in our validation rule. However, we’ve already locked ourselves into an after-save flow with this approach, and this would require precise timing of a Create Records and a Delete Records element. Not to mention, this would cause a noticeable slowdown in performance. While theoretically possible, it’s not worth the tradeoffs.
  • Custom Setting/Custom Metadata. Like the permission set solution, we could check/uncheck a box in Custom Settings or Custom Metadata. In addition to the tradeoffs mentioned above, it’s a bit harder to reference in a validation rule. And, if this is done as an organization-wide setting, it could exempt more records than just the one we want, leading to data quality issues from any other records. It’s also even less performant and can cause deeper system issues due to frequent updates to system settings.

The key theme for all of these methods is that you’re creating or modifying records to turn the rule back on after your flow bypasses it. So, how can we turn them back on without changing anything? Well, there’s one thing that changes without updating anything: time.

By updating a date/time field with the current time, and having our validation rule be bypassed for only the next ~5 seconds, the flow can make the desired updates and update the date/time in one shot. This means there are no performance tradeoffs, and shortly after the flow is done, the rule will go back into effect, once again without performance tradeoffs.

The first thing we’ll need is a custom date/time field for our flow to update. Whenever we want to bypass our validation rule, we’ll update this field to the current time.

The ValidationBypassDateTime custom field

Note that we’ve set the default value to $System.OriginDateTime. This ensures that the field isn’t blank and starts with a value in the past. Make sure that Field-Level Security is either set to ‘No Access’ or ‘Read Only’ for all profiles.

Next, we need to build out the logic for the validation. This can be done either directly in the validation rule or as a checkbox formula. Having a checkbox formula lets you reuse this in multiple validation rules easily, so we’ll choose a checkbox formula.

The IsVRBypassed formula field

Let’s break this down: BLANKVALUE(ValidationBypassDateTime__c, $System.OriginDateTime) > NOW() - 0.00005787037 /*Five Seconds*/

  • BLANKVALUE(ValidationBypassDateTime__c, $System.OriginDateTime) — ValidationBypassDateTime__c should be the time set by our flow. In case it doesn’t have a value for whatever reason, the BLANKVALUE function will instead make sure we use a value in the past instead.
  • NOW() - 0.00005787037 /*Five Seconds*/ — NOW() gives us the current time, but in order to specify an amount of time to wait, we’ll need to subtract a bit from this value. ‘1’ would be a day, so we need to do a little math to get to seconds. So, our equation looks like this: 1 (day) / 24 (hours) / 60 (minutes) / 60 (seconds) * 5 = 0.00005787037. It doesn’t have to be 5 seconds, but it’s a good place to start.
  • Putting it all together, this formula evaluates to TRUE and will bypass our rule if Flow has modified the record within the last 5 seconds.

Next, we need to add it to a rule.

A validation rule that has our bypass logic added to it

We’ll once again break this down: (ISNEW() || ISCHANGED(Category__c)) && ISPICKVAL(Category__c, "Perfect") && !IsVRBypassed__c

  • (ISNEW() || ISCHANGED(Category__c)) && ISPICKVAL(Category__c, "Perfect") — This is essentially the rule we want to bypass, and you’d replace this part with your own rule. The most important thing is to make sure it has parentheses surrounding it so we can do the next part.
  • && !IsVRBypassed__c — First, we have the “&&” piece. It’s shorthand for AND(Argument_1, Argument_2). IsVRBypassed__c is our custom formula with logic in it, of course. When it evaluates to TRUE/checked, we don’t want our rule to fire, so we use an !, which is shorthand for NOT(), to change it to FALSE.
  • Putting it all together, this reads, “When the record is created, or the category is changed, and category is set to ‘Perfect’, and the validation rule has not been bypassed by a flow, then give an error message to the user.”

Lastly, we need to update our flow to leverage our new bypass logic. In your Assignment or Update Records element, set the ValidationBypassDateTime to {!$Flow.CurrentDateTime}.

A Flow Assignment element where we've set ValidationBypassDateTime to the current time

Business results

Since you can guarantee that no conflicts between flows and validation rules will happen, the two can work in parallel, users are free to make their changes without being blocked with an error message, and flows can make their updates as intended, leaving your inbox free of error emails you have to troubleshoot.

Do try this at home

Once you’ve activated your flow, from now on, it will bypass any validation rule that you’ve added the && !IsVRBypassed__c piece to. And a few seconds later, the bypass will expire and users will receive errors as normal for that record.

Resources

Want to see more good stuff? Subscribe to our channel!

SUBSCRIBE TODAY