One Rule, Two Entry Conditions

Two flags. One agreed rule. Three different opinions about when it applies.

Nobody wrote the state where it breaks. It assembled itself out of two correct components.

What the rule was supposed to be

The acceptance criteria are not vague about this one. The suppression state is both flags true: Is_Migrated and Locked. When that state holds, the feature stops.

Stopping means two things in practice. The record cannot be edited, and its orchestration cannot start.

Two enforcement points, one agreed condition. That is the sort of sentence I used to read and move past.

What was actually deployed

The orchestration side of the rule is a clause on entry conditions, and it is deployed in 84 places. I pulled all 84 out and compared them against each other.

They agree perfectly. Byte-identical. Never nested under an OR, always ANDed at the top level. If you were looking for a deployment inconsistency, there is none to find.

They also check one flag, not two.

The validation rule on the same feature checks both.

The state where they disagree

Is_Migrated = false. Locked = true.

The validation rule wants both flags true before it blocks an edit. It has one of them. So the record is editable.

The orchestration gate evaluates a single field. Work backwards from the behaviour and there is only one candidate for which field that is — the lock is set, and the plan will not start.

Editable record, blocked orchestration. Same feature, same record, same instant, two opposite answers to "does the rule apply right now."

That combination appears in no acceptance criterion and no test case, because no author of either component was thinking about it. Each was solving their own half.

What this was not

It was not a deployment error. All 84 instances are identical.

It was not a requirements gap. The acceptance criteria state the two-flag condition plainly. Somebody did decide.

It was not a bug in either component, judged on its own terms. Read alone, the single-field gate is arguably the better design — it is the simpler condition and it is the one that holds uniformly across all 84 instances. Read alone, the validation rule implements the written requirement exactly.

And it was not reachable by either component's own tests. Test the validation rule against its condition and it passes. Test the orchestration gate against its condition and it passes. The defect lives in the gap between two green results.

Why nothing in the review path catches this

Each artefact was reviewed by someone competent, against the thing it was supposed to do. The acceptance criteria as requirements. The validation rule as a validation rule. The orchestration configuration as orchestration configuration — and, being uniform, it reviewed extremely well.

Nowhere in that path does anybody hold the three side by side and ask whether they start at the same moment. There is no review step whose job that is. It only becomes visible when one person reads the acceptance criteria, the orchestration data and the validation rule together — a tester's job by default, because nobody else has a reason to open all three.

The deliverable is the entry condition, not the rule

A feature enforced in two places has two entry conditions unless somebody deliberately makes it one. Deliberately. Not by everyone reading the same requirement — that is exactly what happened here, and it produced two conditions anyway.

So when a rule is enforced at more than one point, this is what I now do before writing any test case:

• Enumerate every point where the rule is evaluated. Validation rules, orchestration entry conditions, Flow decision elements, Apex guards, button visibility. Not every point where it is described — every point where it is decided.
• Diff the conditions literally, field by field. Not by intent, not by summary. Two conditions that both "implement the suppression rule" can differ by one field and read identically in a review comment.
• Build the states where they disagree. With two boolean flags and two enforcement points, the disagreement space is small enough to enumerate on paper. Those states are the test cases nobody wrote.

The lesson I took away

Uniformity within one component tells you nothing about agreement between components. All 84 clauses matching each other made the configuration look thoroughly settled, and that impression is precisely what stopped anyone asking what the other half was checking.

The bug is never in the state everybody agreed on. It is in the state where two defensible answers meet.

Pick a rule your system enforces twice. Can you write out both entry conditions from memory — and would they match?