Reading the consent and suppression ledgers
Two different stops on an outbound message, shown as two separate tables — one records what a resident agreed to, the other overrides it regardless.
This screen is a read surface, not a form — there's no button here to grant, revoke, or suppress anything. What it gives you is the two ledgers that decide, together, whether a resident receives a given campaign at all.
The consent ledger
Every consent decision ever recorded, for every resident, purpose and channel — not a collapsed "current status" view. That's deliberate: the question this ledger has to answer is "when did they agree, and to what wording," and a single current-state field can't answer that. Each row shows the resident reference, the purpose, the channel, the decision (granted, revoked, or denied), where the decision came from, and exactly when it was recorded.
The suppression list — a stronger, separate control
Suppression is not "no consent on file." A resident can have granted consent for a purpose and channel and still be suppressed — suppression overrides consent, never the other way round. Each entry names its scope (a specific channel, or every channel), the reason it exists, when it took effect, and an optional note.
The distinction matters operationally: a resident with no consent record simply hasn't been asked yet, or hasn't answered. A suppressed resident has been explicitly excluded — treat the two very differently when you're investigating why a campaign didn't reach someone.
Why this screen has no write actions today
Consent decisions and suppression entries are written by the systems that actually observe them — a resident's own reply, a channel provider's bounce or opt-out signal, a compliance process — not typed in by an operator after the fact. That's consistent with the platform's own rule that resident-level data like this is read under its own permission (outbound.resident.read, distinct from ordinary campaign permissions) and never asserted by whoever happens to be looking at a screen.
If you need to understand why a specific resident isn't receiving a campaign, check both tables for that resident's reference before assuming it's a channel or template problem — a suppression entry silently wins over everything else in the send path.