The Config That Quietly Waives Your Governance

The approval control worked. I tested it. It approved what it should approve and routed what it should route.

Then I read the code, and found the branch that runs before any of that.

The Branch That Runs First

Before the resolver loads a single threshold, it checks a list held in custom metadata. If the discount's template code appears on that list, the method returns auto-approved — at any amount, with no manager involved.

Two rows were active. Both were −100% "free bundle" offers.

And the design is defensible. Catalogue offers that are free by definition should not each require a manager's signature. As a mechanism, it is sound. That is exactly what makes it dangerous as a finding: it looks correct, so nobody raises it.

Three things made me raise it anyway.

There is no requirement for that list anywhere in the backlog. It appears in no acceptance criterion. It is absent from the approval process design document. Somebody added it — most likely for a demo, or after a conversation in a chat thread — and it stayed.

And it has a latent trap. A row with a blank code field would match every discount and blanket-approve the entire org. Nobody owns who may add rows.

The Second Hole: No Rule Means Yes

While reading the same resolver, a different gap appeared.

Any product with no matching row in the threshold metadata is auto-approved. Any amount. So is any unrecognised pricing code.

Most of the catalogue has no row.

The technical design specifies the opposite: a product with no matching rule must hard-block and reject, described in the document as a conservative default. The build has no hard-block tier at all. Confirmed live on the org.

So the running system is materially more permissive than its own written design, and the difference is invisible from the outside because both produce a screen that says Approved.

The Part That Changes How You File It

Both branches are pinned by green unit tests. System.assertEquals('AUTO', results[0].approvalTier).

That single line changes everything about how this should be raised.

A test suite records what the developer believed the code should do. Once a dangerous default is asserted, it stops being a bug and becomes the specification. Code review passes. Deployment passes. QA passes. The only artefact that disagrees is a design document nobody re-reads.

File it as a defect and you will get works as designed — and that verdict will be correct. You will also have spent your credibility arguing with someone who is right.

Raise it instead as a requirement question, addressed to whoever owns the business rule:

Is the business aware that a product with no configured limit can be discounted to zero, auto-approved, with no manager involved?

That question cannot be closed by a developer. It has exactly one honest answer, and either answer is useful: yes, intended, document it — or no, and now you have a real story with a real acceptance criterion.

Read the Test Class as a Coverage Map

There is a technique hiding in this.

The same suite asserted every failure path — error, no-match, both auto fallbacks — and never once asserted the manager branch or the threshold boundary the feature exists to enforce.

So the test class is not just a safety net. It is a map of what the developer thought about. The branches it never asserts are the ones nobody has considered, and they are where your test design should go first.

That is a faster route to the interesting cases than reading the requirement, because the requirement describes intent and the test class describes belief.

What To Do With "Undocumented But Working"

This class of finding does not belong on the defect board, and it does not belong in a drawer either.

It is handover debt — the sort of thing that costs nothing while the people who built it are still around, and costs a great deal the moment a system changes hands.

Route it accordingly:

• A risk register entry, not a bug. One line describing the mechanism, one line describing the exposure, and a named owner question: who is allowed to add rows to this list?
• A regression check on the mechanism itself. Assert that the bypass list contains only the rows the business has agreed to. That check will outlive everyone who remembers why the list exists.
• An explicit note at handover. When a client takes a platform over from a supplier, the undocumented back doors are the first thing that should be on the table — not because anyone acted badly, but because knowledge that lives only in people leaves with them.

Config that quietly waives your governance is not a scandal. It is ordinary. It gets added for good reasons under time pressure, it works, and it travels into production with the next deployment package because no test and no document knows it is there.

What runs before your approval control — and who is allowed to change it?