Consent & preference centre architecture

The problem

Consent rarely lives in one place. A subscriber can unsubscribe from a footer link, a service agent can tick a box in CRM, and a preference page can write its own record. Without a deliberate design, all three are true at once and none of them agree.

Approach

Decide which system is authoritative for each kind of consent, and write that down before building anything. Channel-level opt-out and topic-level preferences are different questions and often have different owners.

Model preferences as data rather than as a page layout: a preference record keyed on the contact, with topic, channel, value, source, and timestamp. The page then becomes a view over that model instead of the model itself.

Keep the synchronisation direction explicit. Bidirectional sync without a last-write-wins rule and a source field is how two systems overwrite each other in a loop.

Treat the global unsubscribe as a hard boundary that topic preferences cannot override.

Failure modes worth designing against

A preference page that writes only the topics shown on screen, silently resetting topics that were hidden by a filter.

Sync jobs that carry no source or timestamp, making conflicts unresolvable after the fact.

Unsubscribe handling that is correct per business unit but wrong at the enterprise level, or the reverse.