Consent-Revocation Suppression Integrity Automation: Whoever Revoked Kept Being Contacted

A consent-revocation feature can be implemented correctly at every layer a person actually sees — a clear toggle, a confirmation message, an updated status on screen — and still fail entirely at the one layer nobody sees directly: whether the specific database write meant to enforce that choice going forward actually succeeds. When that write is silently rejected and nothing downstream notices, the interface and the database tell two different stories, and only the database's version is the one that determines whether a message actually goes out.

The consent-revocation handler's job is straightforward in principle: when a contact revokes consent, write a record that future outreach logic will check and refuse to act against. The handler did exactly that — it just wrote the record using the wrong shape. It supplied the contact's internal ID and a field describing which type of consent was revoked, when the actual suppression table identifies a record by the contact's e-mail address or phone number directly, tagged with which of the two it is, and carries no field for consent type at all. Because the database's own schema enforces this strictly, every attempted write was rejected outright.

The fix restructures the write to match what the table actually expects: before inserting a suppression record, the handler now looks up the contact's own e-mail and phone number directly, and writes the suppression keyed to whichever of the two identifies the revoking contact — populating both the identity type and the identity value the table's own schema actually requires. This is a structurally different lookup than the original code performed, not a renamed field on the same shape, because the suppression table was designed around identifying a person by a reachable address, not by an internal record id that a downstream send-check would have no reason to look up on its own.

This specific defect was found only after a broader schema-comparison gate — built to catch a database write pointed at a table name that does not exist — was itself extended to also verify the shape of what a write sends: comparing field names, not merely table names, against the live database's real schema. That extension is what surfaced this defect and several siblings in the same investigation, none of which the original, narrower version of the gate could see.

A contact clicks to revoke marketing consent, sees a confirmation, and reasonably assumes the matter is settled. Before the fix, the suppression record meant to enforce that choice fails to write, silently, and the very next scheduled campaign still considers that contact eligible — the revocation changed nothing about what actually happens next. After the fix, the identical revocation resolves the contact's e-mail or phone directly and writes a suppression record the send-check logic can actually find, and the next campaign correctly excludes them.

A contact who revokes marketing consent through Centriu Flow now has an actual, enforceable suppression record created at the moment they revoke it — closing a gap where the interface reported success while the underlying database write silently failed every time.

This automation governs the specific database write that turns a consent revocation into an enforced suppression inside Flow — it is not a general compliance-governance or audit-trail product; Centriu TrustOps serves that broader purpose as a separate system.

Confirming a consent-revocation feature works by checking that the interface shows a confirmation message tests exactly one layer of a multi-layer system — and it is precisely the layer least likely to reveal a database-level rejection happening underneath it. Centriu's fix was found and verified at the layer that actually determines behavior: whether the record a send-check depends on was ever really written, confirmed against the database's own live schema rather than assumed from how the interface responds.