Reconcile the Coverage Claim Against the Org

A developer hands over a list. Forty-one orchestration scenarios. Thirty-eight item definitions. All covered by the change, unit tests complete, no impact observed.

Everything in that sentence is true except the list.

The Gap Is One Record, in the Worst Possible Place

Query the org for the same clause and it comes back on 40 of the 41 scenarios.

One record was declared and never implemented. Not a naming mismatch, not a caching artefact — the clause is simply not on it. And the scenario carrying the hole is the one hanging off the orchestration plan that pushes the order into the billing system, which is the area the whole mechanism was built to protect.

Read that again, because the arithmetic is the point. The declaration and the org disagree by exactly one record out of forty-one, and that one record is the only one whose absence has a price attached.

That is not bad luck. It is what drift looks like when the list is written by hand: the records that get remembered are the ones the developer was actively thinking about, and the ones that get forgotten are the ones that felt like somebody else's area. Billing usually feels like somebody else's area.

The List Was Produced From Intent

Nobody lied here, and treating this as a trust problem gets you nowhere.

A coverage list gets written the way anyone writes one. From memory of the work. From the tickets that were open that week. From the sections of the design that were on screen while the change was being made.

It is an honest statement of what the developer set out to do.

It is then read as a statement of what the org now contains. No step anywhere between those two readings converts one into the other. The org was never asked to confirm anything, and a document that has never been checked against a system is a plan, not a record.

Absence Does Not Throw

The unit tests are the part that fools people, so it is worth being precise about why they were useless.

Unit tests exercise a code path. They set up data, run the logic, assert the outcome. When the clause is present and the logic is right, they go green — correctly.

A configuration record that simply has no clause on it never enters the path at all. There is nothing to execute, nothing to assert, and therefore nothing to fail. The missing record produces a missing test, not a failing one. A green suite is an honest report about the code and completely silent about the inventory the code is supposed to apply to.

That distinction — code coverage versus configuration coverage — is where declarative platforms quietly break the habits you brought from everywhere else. On Salesforce, a large share of behaviour lives in records: entry conditions, item definitions, metadata rows, criteria on flows. Apex tests do not enumerate them. Nothing enumerates them unless you do.

Reconcile by Query, Not by Execution

The instinct when handed a coverage list is to test it. Pick the scenarios, build the data, run them.

Forty-one orchestration scenarios is days of work, most of it environment wrangling, and at the end you would have executed maybe a third of them and reported a sample.

Querying the org for the clause is minutes. Then you take a set difference between what was declared and what came back, and the answer is a defect list rather than a coverage percentage.

• Ask for the declaration in a form you can diff. A list of record names or IDs, not a paragraph. If what you get back is prose, convert it yourself and send the converted version back for confirmation — that round trip alone catches things.
• Query for the artefact itself, not for a proxy. The clause on the record, the permission on the profile, the field on the object. Anything one level away from the thing being claimed will agree with the claim for the wrong reasons.
• Compare in both directions. Declared-but-absent is the defect you are hunting. Present-but-undeclared is the other half, and it tells you the change touched something the developer did not realise was in scope.

Two of those three take a single SOQL query and a spreadsheet column.

Treat the Declaration as a Test Artifact

This is the reframe worth keeping.

A developer's coverage note usually arrives as context. Background reading. Something to skim before you decide what to test.

It is not context. It is an assertion with a specific, checkable claim in it — these forty-one records now carry this clause — and an assertion that nobody verifies is exactly the kind of thing your job exists to catch. The fact that it arrived in a comment rather than in a test case does not change what it is.

So handle it the way you would handle any other assertion. Find the cheapest way to evaluate it. Record the result. When it disagrees with the system, that is a finding, not a misunderstanding to clear up in a chat thread.

Why It Survives Review

Reviewers check reasoning. The list explains itself well: here is the change, here is where it applies, here are the counts, here is the test result. It reads as thorough because it is thorough about everything it discusses.

What no reviewer does is count the records in the org, because doing so feels like distrust and because nobody has the list of records in front of them in the review. The inventory is the one part of the claim that cannot be evaluated by reading, and it is the part where the drift lives.

The strange part is how cheap the check is once you accept that framing. Minutes of querying against days of execution, and it finds the records nobody would have thought to run — because the reason they were not run and the reason they were not implemented are the same reason.

The last coverage list you were handed: did you test against it, or did you ask the org whether it was true?