Salesforce Approvals Beyond Flow: What to Build Instead

A Salesforce approval process beyond Flow is not a bigger flow. That is the first thing to get straight, because almost every org that hits this wall responds by making the flow longer — another decision element, another branch, another subflow — until the whole thing is unreadable and exactly one person understands it.

The wall is not complexity. It is shape. Both the classic approval process and Flow ask you to express an approval as a path: first this person, then that person, branch here, skip there. Your business does not describe approvals that way. It describes them as a rule about data. Deals over 30% off go to the regional director, unless it’s a renewal, in which case it goes to the finance partner assigned to that account — and if she’s out, her delegate.

You can draw a path that satisfies that rule today. You cannot draw one that still satisfies it next quarter.

The approval you can’t draw as a path

Take a real approval rule apart and you find it depends on four different kinds of thing at once: something about the record (discount, margin, term, product line), something about the submitter (their role, their region, their manager), something about the state of the world (who is out this week, which quarter-end it is), and something about history (this customer is already past due, this deal was approved once and then edited).

A path can encode the first one cleanly. It handles the second one awkwardly. It cannot handle the third and fourth at all without becoming a maze, because those change after the path was drawn.

That mismatch has a tell, and most orgs have it: the real approval matrix lives in a spreadsheet. Someone in RevOps or finance maintains it, it has columns for amount band and region and product, and it is the actual source of truth. The Salesforce process is a lossy approximation of that sheet, kept roughly in sync by hand, and the gap between them is where deals get approved by the wrong person — or, more often, by email, which means the approval stops existing as a record of anything.

That is not a governance failure to fix with policy. It is a modeling failure, and it is one of the Salesforce problems that are worth building your way out of rather than documenting your way around.

Where the built-in tools actually stop

It is worth being precise here, because the ceiling is not where people assume. Salesforce’s own limits for classic approval processes allow 30 steps per process, 25 approvers per step, 1,000 active processes per org and 300 active per object. Nobody is running out of steps. The constraint was never volume.

The constraint is the sharp edges, and they land exactly where dynamic rules need room. Salesforce’s considerations for setting approvers state plainly that “a manager’s manager is not an option for a designated approver” — so any rule with two levels of hierarchy in it needs a lookup field that you populate and maintain yourself. You “can assign an approval request to only one queue,” which rules out the common pattern of offering a deal to either of two teams. And “email approval response isn’t supported for classic approval processes that assign approval to a queue,” so the queue route costs you the approval channel your executives actually use. There is also this, which is worth reading twice: processes that let users pick an approver manually “also let users select themselves as the approver.”

Flow-based approvals move the ceiling without changing its shape. Salesforce’s flow approval process limits allow 2,000 active and 4,000 total, with 50 versions per process, and the guidance is to keep flow approval process limits, flow limits and Apex governor limits in mind — three ceilings where there used to be one. That is a real upgrade in capacity. It is still a path. Which tool fits is the same judgment call as Flow versus Apex everywhere else in the org: declarative is right until the logic stops being a sequence.

Build 1: the approver chain as data, not as steps

The fix is to stop drawing the chain and start computing it.

Create a rule object — call it Approval_Rule__c. Each row holds the conditions that select it (object, field thresholds, region, product line, renewal flag), the way the approver resolves (a named user, a role, a lookup on the account, a field on the submitter), a sequence number, and an active flag with effective dates. On submission, one invocable method evaluates the rule set against the record and writes the resulting chain onto the record as approval step records.

Two things change immediately. First, policy edits become row edits — the RevOps lead who owns the matrix owns it in Salesforce, and changing the discount band no longer requires a release. Second, the chain is a snapshot of what the rules said at that moment, which is what makes everything downstream possible.

This is the same pattern that works for lead routing that respects real territory rules, for round-robin assignment that doesn’t skip people, and for duplicate matching on your definition of a duplicate rather than the platform’s: the rules are data, the engine is small and boring, and the business edits the data. If the authoritative approver list already lives somewhere else — an HR system, the ERP, the finance team’s own tooling — that is a sync, and connecting Salesforce to the system your ops actually run on is a smaller job than re-keying the matrix every quarter.

Build 2: the clock nobody is watching

Ask an org what happens when an approval sits untouched for three days and you usually get one of two answers: nothing, or “the rep chases it.” Both mean the same thing. Escalation is a manual process performed by whoever is most annoyed.

The build is a scheduled job that ages pending approvals and acts on them. Nudge at one threshold, escalate at another, and put both thresholds in the same rule table as everything else so the policy stays in one place. The details that make it useful are the unglamorous ones: business-day math rather than calendar days, awareness that the last week of the quarter is not a normal week, and an escalation target that resolves the same way approvers do, so “skip to the regional director” doesn’t hardcode a name that changes in March.

Do this and the stale-approval report stops being something a human runs. The approvals that need a person get one, on a clock, and the ones that don’t quietly clear.

Build 3: what happens when the record changes after submission

This is the one that quietly makes approvals meaningless, and almost nobody has an answer for it.

A deal is submitted at 28% off and routes to the sales manager. While it sits there, the rep edits the discount to 41%. The chain that was computed no longer matches the record. If the manager approves, the deal is approved by someone who, under your own policy, was never supposed to see it — and the approval history will look completely clean.

There are three defensible answers and you have to pick one on purpose. Recompute the chain on change and extend it with whoever the new numbers require. Invalidate the approval outright and restart. Or lock the fields that drive the chain for the duration, so the record can’t drift under the approver. Which one is right depends on how your team works; having none of them is the only wrong answer.

Whichever you choose, it is a small build — a trigger that compares the driving fields against the values stored on the chain, and one decision about what to do when they differ. It is also the single highest-value hour in this whole list, because it is the difference between an approval process and a formality.

Build 4: the decision record you can actually report on

Eventually someone asks why a particular deal was approved by a particular person, and the answer has to be reconstructable a year later, after the rules have changed twice.

So store it. A decision record per approval step: the rule version that fired, the field values it evaluated, the resolved approver, the outcome, the timestamp, the comments. Not a log of what the system did — a record of what the policy said, at the moment it said it.

This is what turns approvals into something you can report on instead of something you can only audit by clicking into records one at a time. Cycle time by rule, escalation rate by region, which bands never get rejected and could simply be raised. Those are the reports people are told Salesforce can’t build, and they can’t be built because the underlying data was never captured — not because the report builder is weak.

What changes once the chain is computed

The approval matrix stops being a spreadsheet. Policy changes take an afternoon instead of a release. Reps stop structuring deals to avoid approvals, because approvals stop being a tax with unpredictable latency. And finance gets a question answered — who approved this, under which rule — without anyone reconstructing it from email.

There is a quieter benefit that shows up about a month in. Once the rules are rows, you can read them — all of them, at once, in a list — and orgs almost always find two or three that contradict each other, plus one that has been silently routing a whole product line to someone who left. That audit is impossible when the policy is spread across a 40-element flow and three deactivated processes nobody wants to touch.

It also closes the loop on the quote process itself. A quote that routes on margin rather than total amount only works if the routing engine can express “margin” as a rule, and that is exactly what Build 1 gives you. The same is true of anything else you want gated by judgment instead of by a number — credit terms, non-standard SLAs, early renewals.

Why this one never gets built

Not because it’s hard. Because of where it sits. Each of these four is a day or two of work, which is too small to become a project with a budget, and too technical to be an admin’s Thursday afternoon. So it goes on the list, and the list has a quarter of work on it, and approvals keep running in email.

That queue is the actual problem, and it’s the one Sentinel exists to shorten: your AI connects to your org and becomes the developer of it, so “route approvals off a rule table and escalate after two business days” is something you describe and watch get built rather than something you file. The reason that is sane rather than reckless is visibility — every change is logged, snapshots are taken before deploys, and Salesforce changes go to a sandbox with tests before they reach production, so a bad rule is something you find and roll back the same day. If you’d be the one accountable for it, how that safety layer works is the piece to read next.

Pricing is flat per Sentinel and is covered on a short demo call.

Where to start

Start with Build 3. Not Build 1 — Build 3. Find out what your org currently does when a record changes mid-approval, and if the answer is “nothing,” you have a policy that is already not being enforced, and no amount of routing sophistication fixes that.

Then do Build 1, because it makes the other three cheap. The practical first step is pointing your AI at the org and asking it what the current approval processes actually do — connecting Claude to Salesforce takes an afternoon, and reading the existing processes back in plain English is usually enough to find the two nobody knew were still active.

One thing not to do: rebuild the maze in a new tool. If the rule genuinely is “manager, then VP, then done,” the classic approval process handles it and always has. This is not an argument that declarative approvals are bad. It’s an argument that the moment your rule has an unless in it, you have left the territory those tools were designed for, and building a small engine is cheaper and more honest than pretending otherwise.

Book a Demo Call and bring the spreadsheet your approval matrix actually lives in. That sheet is the spec.