Admins / Flow

An Admin’s Guide to Bypass Logic for Flows, Apex, and Validation Rules

By Tom Bassett

As Salesforce Admins, Developers, Consultants (and more), we have a whole host of tools to automate whatever our users need. 

Whether we are using Validation Rules, Flows, or Apex, these can be tailored for our specific use cases. But what about when we need exceptions or want to load data? Bypass Logic helps by providing a framework to bypass automations in a way that is flexible. 

What Is Bypass Logic?

You can implement a Bypass Flag in many different ways, either using Custom Settings, Custom Permissions, or something else. 

These generally provide an ‘off switch’ for Validation Rules, Flows, and Apex Triggers. When it comes to Flows, they are typically applied only to record-triggered automations. You can also apply them to User Access Policies, Approval Processes, and other types of automation. However, by applying them only to Validations, Flows, and Triggers, I can control what does or doesn’t fire – which is why I don’t usually bother with other types of automation.

By creating three Custom Settings or Custom Permissions for Bypass Flows, Bypass Triggers, and Bypass Validation Rules, you lay the groundwork for automations to check these before running your logic or error condition.

My preference is for Custom Permissions managed via Permission Sets and Permission Set Groups. This way, you can assign these on a one-off basis and optionally set them to expire at a set date and time at an individual user level. 

Use Cases

What if you need to load data but don’t want to fire the logic that runs on creation or update? Automation could be sending an email, updating a related record or doing something else. Assuming this is in a series of record-triggered flows, you could assign the user a Bypass Flag so that Flows don’t fire temporarily. Once they’ve handled the data load, then the bypass can be removed. This would happen without interrupting other users, where automations would still run.

A Flow that checks for Bypass Flows in the Entry Condition

Let’s say you have a Validation Rule to stop users from entering bad data. What if you didn’t want this to run for an integration user? Assign them Bypass Validation Rules, and away they go. Validation Rules would still apply to other users, but wouldn’t hold up the flow of data between different systems. This is a simplified example, as in reality, you’d want to stop bad data from coming into the system in the first place, but it should give you an idea of how things could work.

A Validation Rule that checks for Bypass Validation Rules in the Error Condition

Suppose you have an Apex Trigger that calls out to an External System. This could schedule a task in the background to then call out the system in the background. If you had the finance team updating some records manually and you didn’t want these to sync to the External System, then you could temporarily assign the finance user a bypass and remove this when they’re done.

Apex Trigger that will only run if the running user does not have Bypass Triggers

Considerations

Bypass Logic is great and everyone should be using it, but it does come with some drawbacks.

This provides a flag at a metadata level to stop all Flows, Validation Rules, or Apex Triggers. If you wanted to only turn off specific automations, then you’d need to use a different approach.

If you inherit an existing Salesforce org without Bypass Logic, then the effort to refactor all Validation Rules, Flows, and Apex Triggers could be considerable if a lot is happening – and that’s before you think about testing! 

It’s important that users know they have been assigned a bypass, as this can alter the user experience. For example, the email they used to get when a Project Budget was created would no longer work if they were granted Bypass Flows permissions, which could cause confusion. 

Managed Packages provide read-only solutions and so you won’t be able to edit managed code to include your org-specific bypass logic. However, some packages, such as NPSP, include Trigger Handler records which are a different way of controlling which Apex Triggers do or do not run.

Final Thoughts 

Bypass Logic is a must for every Salesforce Admin to provide a global off switch for automations when they need to do a data load or handle exceptions to the normal processes.

By granting these to users via Custom Permissions and Permission Sets, you get the added flexibility that Permission Sets, Permission Set Groups, and Permission Set Expiry bring. 

Other Resources

The Author

Tom Bassett

Tom is a 33x Trailhead certified, 2x Slack certified, and an 11x accredited professional with over six years of experience in the Salesforce ecosystem.

Leave a Reply