The Bug Fix That Would Have Cut Off Users

A pricing bug fix is supposed to make numbers more accurate. This one, left to run through the rest of the engine untouched, would have quietly stripped a core application from almost every user who had it.

The setup: once the engine finally started pricing D365 service operations correctly, a custom login privilege on one client flipped from a free Team Members privilege to a Full privilege requiring four separate app licenses. Its disposition had been 227 users on `stays_covered_by_seat`, 21 on `stays_as_is`, and 13 on `drop`. After the price correction, coverage failed for nearly everyone holding it, and the decision for most of them became `drop`. The rebuilt design would have shipped with the login removed.

Fixing a pricing bug would have silently removed access. Here is why, and what stopped it.

Service operations leave no evidence

The redesign engine is evidence-based. Its core rule is simple and usually right: if there is no evidence a privilege is used, propose dropping it. Evidence comes from telemetry and from the audit log, the traces a person leaves by opening forms and committing records.

Service operations produce neither. They are invoked by integrations and background processes, not clicked by a user. There is no form open, no menu-item hit, no audit row that ties a named user to the operation. A privilege whose only paid content is service operations is, by construction, unobservable. It will always look unused, because the thing that would prove use is never recorded.

While service operations were priced as free, this did not matter. An unobservable privilege that costs nothing is harmless to keep, and the engine kept it. The moment the pricing bug was fixed, the same privilege became expensive, still unobservable, and therefore a prime `drop` candidate. The fix did not create the access risk. It armed one that had been sitting dormant.

The two ways it would have removed access

By dropping the privilege. For a privilege that is not audit-blind, no evidence plus a now-expensive tier equals `drop`. The login privilege above is the clean example: 13 users on `drop` before the fix, almost all of its holders on `drop` after.

By failing a safety test. A privilege made entirely of service operations is flagged audit-blind, so it is not dropped outright. Instead it fails the build's tier-safety check and is pushed onto a review list, which removes it from the shipped design just as effectively. On one client whose package was already live, this would have pulled two provisioning and project web-service privileges out of roles held by dozens of users each.

There was also a quieter version. One trimmed privilege reached the Activity tier only through about 30 service operations. It was keeping 512 users covered, 409 of them on Team Members seats. After the fix, those 409 would have lost it, for lack of evidence that can never exist.

In every case the pattern is identical: the privilege's license tier rose because of something you can never observe, and the "no evidence, drop it" rule then removed it.

The fix: decide twice, then compare

The rule that absence of evidence is not evidence of absence was already in the engine for audit-blind privileges. Service operations forced that rule to grow a second dimension. It was no longer enough to protect a privilege from being dropped for lack of evidence. A privilege could now be removed because its tier rose, and the thing that raised it was unobservable.

The response was to compute each privilege's requirement twice:

• - once from all of its entry points, including service operations;
• - once from its non-service entry points only.

Then compare the two decisions. If the privilege is fine on the non-service requirement but drops, downgrades, or loses coverage on the full requirement, then its service operations are the only reason it looks removable. The rule we designed says that privilege should not be dropped. It is given a new disposition, keep and price it, so the build would keep it on every path instead of pruning it. User evidence is credited only from the non-service side, so service operations do not masquerade as proof of use and do not, by themselves, condemn a privilege. This is a rule in the method, stated here as the principle it enforces.

This one rule covers all three failure modes at once: the privilege dropped for lack of evidence, the pure service-operation privilege bounced to a review list, and the Activity-floor privilege quietly lost by hundreds of users.

The principle it generalizes

The original guardrail was about removal: never auto-drop a securable you cannot observe. Service operations extend it one step. It is not only the keep-or-drop decision that can be poisoned by an unobservable securable. The license tier itself can rise because of one. And a tier increase, fed into evidence-based pruning, removes access just as surely as a drop decision does.

The general form: if you cannot observe a securable, it must never on its own make a privilege cheaper to remove than to keep. Price it, keep it, and surface it for a human to review. Do not let an unobservable cost become a silent reason to take access away.

Bottom line

A correct pricing fix is not safe to ship until you have checked what the rest of the pipeline does with the newly expensive privileges. When the thing that got more expensive is something you can never observe being used, evidence-based automation will try to delete it. Decide twice, compare, and keep what only looks droppable because of what you cannot see.

Frequently asked questions