The Auto-Approval Feature That Quietly Rewrote Curated Data

A previous release allowed a payment-confirmation webhook to update a registration status automatically. For one organization that tracked approval by hand, the automation overwrote curated decisions. No request failed. The background process did exactly what it was configured to do, but the policy behind the write was incomplete.

The issue was not a crash or stack trace. It was a feature succeeding technically while changing a field whose meaning varied by tenant. That failure mode can remain invisible until an administrator notices that a carefully managed workflow no longer reflects their decisions.

What the feature did

A release added a payment-confirmation-driven status update. The intended convenience was understandable: when payment was confirmed, the system could advance a related workflow without an extra click.

But payment confirmation and approval to participate were different facts. Some administrators used approval to reflect eligibility, paperwork, capacity, or other local policy. The automation collapsed those facts into one field and allowed the payment event to overwrite a human decision.

One organization used the field that way. Its manually curated decisions were replaced by the webhook’s status update. The incident made the policy gap visible.

The fix had two halves, and you need both

The instinct is to “fix the bug.” Roll back the write, ship it, done. That’s only half the job here, and it’s the less important half.

Half one: make the new write opt-out-able per tenant

The automation was useful for some organizations, but usefulness did not make it safe as an unconditional write. The remediation made the policy explicit and tenant-aware, with clear ownership, discoverability, and auditability for the setting.

The correct default for a newly introduced automated write depends on the risk, the established contract, the reversibility of the effect, and whether tenants have been informed. Where a field can encode a human decision, the safer design is often to preserve the separate facts and let an explicit workflow determine any state transition. If an organization opts into automation, the system should record the policy, the triggering event, and the resulting write so the action can be explained and reversed.

Half two: get the clobbered data back

The policy control prevented further overwrites. It did not repair the curated decisions that had already changed. Those records required a separate recovery plan.

The recovery process compared a reviewed candidate set against a point-in-time reference and proposed only records matching the verified incident pattern. Before applying anything, the team reviewed the dry-run output, captured the affected current state, obtained approval, and logged each change. The process remained narrow by design: it was not a generic restore button and it avoided overwriting legitimate changes made after the incident.

A surgical, auditable recovery is preferable to a wholesale restore when the latter would discard valid work performed after the reference point. The same restraint that prevents a broad automation write should govern the repair.

Related

• When the Paywall Flow Is Broken, Build the Staff Tool: Dry-Run, a Cap, and an Audit Row: designing operational tools with bounds, dry runs, and evidence
• The Dry-Run That Lied: When —dry-run and —apply Run Different Code Paths: why a safety check must exercise the same path as the real write

dxdev LESSON · paste into your AI coding agent
LESSON: Gate automation writes that touch human-curated data
SOURCE: dxdev.com/blog/automation-that-clobbered-user-data-opt-out-plus-restore

WHAT HAPPENED:
A background webhook handler updated a status field for every tenant without knowing that some tenants managed the same field by hand.
The automation completed successfully but overwrote curated decisions without an alert or review step.
The root cause was collapsing separate facts-payment confirmation and human approval-into one write without an explicit policy or control.
Recovery required tenant-aware controls, a clearly scoped candidate set, a dry run, approval, audit logging, and a reversible restore process.

THE RULE: Before automation writes a field, identify every human and system that can also write it. Model distinct business facts separately, make the write policy explicit per tenant or workflow where appropriate, preserve provenance, and ship a tested recovery path with the change.

CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any automated writer that changes a status, approval, or classification field without an explicit business policy, provenance, idempotency handling, and an applicable tenant or workflow control.
  2. Any automated write that shares a field with a user-facing workflow but cannot distinguish the underlying business facts or preserve a human override.
  3. Any recovery script without a reviewed candidate set, dry-run output, backup or snapshot reference, approval record, transaction or rollback plan, and audit log of changed rows.

THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.