The Bypass You Already Built (And Why It's a Liability)

If you've been running a Salesforce org for more than a couple of years, I'd bet money you already have some version of an override mechanism in place. You just don't call it that.

Maybe it's a Bypass_Validation__c checkbox on the User or a custom setting that a few flows check before they fire. Maybe it's a Custom Permission called Skip_Automation that got added during a data migration project and never got removed. Maybe it's a hardcoded profile Id sitting in an Apex trigger, added at 11pm the night before a big data load because a validation rule was blocking three thousand records and nobody had time to fix it properly.

None of these were mistakes. Each one was a reasonable, even smart, decision made under real pressure. That's exactly why the pattern is so widespread and potentially dangerous.

The override mechanism nobody designed

Nobody sat down and architected these. They accreted. One checkbox for one integration user. One custom permission for one migration. One hardcoded check for one emergency. Each addition made sense in isolation.

The problem is what you're left holding at year three:

• Four different bypass mechanisms, none of which talk to each other
• No record of who added which one or why
• Flows checking a custom setting that a trigger doesn't know about and vice versa
• At least one admin who has left the company, whose bypass logic is still running in production

At that point, "bypass validation" isn't a checkbox anymore. It's tribal knowledge. It lives in the heads of whichever admins have been there long enough to remember why Skip_VR__c exists and what happens if you ever uncheck it.

Why this is a liability and not just clutter

It's tempting to file this under technical debt and move on. But scattered, undocumented override logic is not a housekeeping problem. It's a governance problem.

You can't answer basic audit questions. If a validation rule was bypassed and bad data landed on a record that matters (a closed-won opportunity, a contract, a compliance-relevant field), can you say who bypassed it, when, and why? For most orgs running a DIY setup, the honest answer is no.

It doesn't scale with your automation. Every new flow or trigger that needs to respect the bypass has to be taught about it individually. Miss one and you get inconsistent behavior. The validation rule fires in one path but not another and nobody can explain why until someone spends an afternoon sorting through debug logs.

It has no lifecycle. Real overrides should exist for a reason and expire when that reason ends. A checkbox has no concept of "this is temporary" or "this needs approval." Once it's on, it's on until someone remembers to turn it off which, in practice, is sometimes difficult.

It's invisible to the people who need to see it. Security reviewers, compliance auditors, and even your own admin team inheriting the org later have no way to discover that bypass logic exists at all unless they happen to stumble into the right flow or trigger.

Naming the pattern is the first step

The point of this post isn't to make anyone feel bad about the checkbox they added in 2021. It was the right call at the time, given the tools available. The point is to name what's actually happening: most orgs already have an override architecture. It's just an accidental one, built one emergency at a time, with no visibility, no audit trail, and no lifecycle.

Once you can see it that way, the next question becomes obvious: if you're already managing bypass logic (informally, inconsistently, and invisibly) what would it look like to manage it on purpose?

That's the question the rest of this series digs into.