Four sales process automations in Dynamics 365 were repaired in one day. What made the day worth writing up is not the repairs, it is that three of them reported success while the branch they added had never executed once. Each fault was found by asking which test actually runs the new code, rather than whether the test suite passes.
- A branch that could not be reached by an empty value was being reached by one. Each automation reads a step field from the record that triggered it and matches it against a list of cases. When that field is empty the platform fails the whole evaluation before it attempts any match, and the default case does not catch it, because a default handles a value that matched nothing rather than the absence of a value. Two internal design documents had reasoned the opposite from the same definition. Both were wrong, and both are now corrected.
- One of the four reported 200 runs and zero failures while carrying the identical defect. Its trigger only fires when a record moves into a closed state, and the records it watches are already closed when they arrive, so the faulty path was never entered. A clean failure count was evidence that the code had not run. It was not evidence that it worked, and reading it as such is how the same fault survived a fix applied to its sibling that morning.
- One automation had been retired because its only working guard was accidental. It closed a process step whenever a note appeared whose subject contained a particular phrase and which carried an attachment. Nothing ever read the attachment. On the day it was examined, six unrelated notes on a single record matched the phrase, and the only reason the step did not close roughly 97 minutes early is that none of them happened to have a file attached. The trigger is now an explicit marker written by the process that completes the work.
- The pattern behind all three was the same, and it is worth naming. Each change also updated the test harness in a way that stopped the harness reaching the new code. The sharpest case: a step that reopens a task when its evidence is missing had been failing on every attempt since it was written, because it set a status value this system does not define, and the same change that added it taught the harness to supply the evidence, so the harness always took the other path. Ask which test executes that specific branch, and be most suspicious when the test was edited alongside the code.