Email Preference Conflicts: Reconcile Account, Topic and Global Opt-Out

TL;DR

• Decide sends by an explicit policy that uses trustworthy event history to resolve conflicting records, not by which database update happened last—apply the rule consistently to the concrete conflict example.
• Model preferences with clear scope and preserved provenance: record what a preference applies to and keep source, effective time and action so merges respect meaning rather than overwriting intent.
• Validate the policy by testing conflicts before campaigns: build fixtures for common contradictions and state, for each contact, whether the optional message is eligible and why.

Start with the conflict you need to explain

An email preference model can contain account settings, topic subscriptions, domain-level scope and broader suppression decisions. Trouble begins when two records disagree and the application has no documented rule for which one controls the next send.

Write the conflict as a concrete example. A recipient previously opted out of optional email, then an old CRM import marks a product topic as subscribed. Should the next campaign include them? The answer must come from an explicit policy and trustworthy event history, not whichever database update happened last.

Give every preference a scope

Record what the preference applies to: a specific topic, a sending identity or domain, an account, or a broader optional-email category. Avoid using one Boolean field to represent several meanings.

For an illustrative product with updates and educational tips, a topic opt-out differs from a global optional-email opt-out. A user can reasonably want one topic without the other, but a narrower subscription should not silently override a broader restriction under a policy that gives that restriction precedence.

Document the rule in language that both engineers and support staff can explain. The schema should preserve enough information to implement it.

Distinguish user decisions from imported observations

A direct preference change by the recipient carries different evidence from a spreadsheet field copied from another system. Preserve the source, effective time and action rather than flattening them into a current value with no history.

In the stale-CRM example, the import may describe an earlier subscription state. It should not automatically be treated as a fresh request to resubscribe. The import process needs an explicit merge policy that respects the meaning of the source data.

The SendDart consent-record guide is relevant to retaining this context. A current checkbox alone cannot explain how or why permission changed.

Define precedence without hiding the reason

Create a decision table for optional campaigns. The application might first check a broad suppression, then the relevant topic choice, then other audience requirements. The exact policy must fit the product and applicable obligations, but it should be deliberate and reviewable.

For each rejected recipient, record a concise reason such as global optional-email opt-out or topic disabled. This is different from a delivery failure: the application correctly decided not to authorize the send.

Do not expose unnecessary personal information in operator reports. A stable internal identifier and reason can support debugging without circulating a full contact list.

Treat resubscription as an explicit transition

If the recipient chooses to receive a topic again, define whether and how that affects a broader preference. Do not make a narrow checkbox silently remove an account-wide restriction.

The interface may need to explain the current broader state and offer a separate intentional action. Alternatively, the product may choose a workflow in which the broader preference must be changed first. Whichever approach is used, the user should understand the consequence.

Keep the new decision's source and time. That allows the system to distinguish a genuine later choice from a delayed synchronization event carrying old information.

Consider concurrent edits and stale pages

A user can change preferences on two devices while an integration updates the same contact. Without a conflict strategy, a stale settings form can overwrite a more recent opt-out.

Use a version or other appropriate concurrency mechanism to detect that the underlying state changed. Then present or apply the conflict policy instead of assuming every submitted form is the newest expression of intent.

For the two-topic example, a stale page editing educational tips should not necessarily overwrite the independently changed product-updates field. Scope the update to the actual action rather than resaving an entire old preference snapshot.

Keep service-message policy separate

Optional-email preferences and required service communication may follow different reviewed rules. Do not solve that distinction by broadly exempting anything an internal team labels important.

For each message type, define its purpose and which preference or policy applies. A marketing campaign should not bypass an opt-out because it is sent through the same technical API as a receipt.

This classification belongs in the application's communication policy. SendDart's delivery resources should implement the authorized decision, not be expected to infer the business purpose from arbitrary content.

Related reading: Scheduled Email Delivery: Store the Time, Content and Cancellation State.

Test the conflicts before launching another campaign

Build fixtures for a global opt-out plus topic opt-in, a topic opt-out plus stale import, a deliberate later resubscription, concurrent edits and an account with unknown preference history. For each, state whether the optional message is eligible and why.

Review the resulting explanation with someone outside the implementation. If the reason cannot be understood without reading database code, the policy may still be too implicit.

A reliable preference model makes contradictions visible and resolves them consistently. It preserves the recipient's actual choices while giving operators a clear answer when a contact appears subscribed in one system but correctly remains excluded from a send.