Cross-channel opt-out propagation

Cross-channel opt-out propagation starts by defining scope and tracing it through every system that can send or export an audience. A request for one channel does not create a universal permission state. Email unsubscribe, SMS STOP, advertising opt-out, data deletion, and service messaging are separate concepts, so apply the restriction that matches the request and respect provider blocks.¹ Carry that decision from the captured request to each sending and export destination. For email and phone work, classify first, sync second, and verify last.

Propagation workflow

Use one path for every request. Keep the original request, its scope, and each destination connected so the handoff remains easy to inspect.

Capture

Start with the request itself. Preserve its original wording as you translate it into the restriction that downstream systems need.

Save the original request, derive the correct restrictions, and deliver them to every affected destination.² Ask: "What exactly did this person ask us to stop, and where did the request arrive?" For a phone request, determine whether the scope covers calls, SMS, or both. If the answer is unclear, resolve it before changing a field or list. The capture is ready when someone else can read it and identify the outreach channel it covers.

Classify scope

Make the scope explicit before syncing anything. Ask: "Should this stop email, calls, SMS, advertising, data deletion, service messaging, or a defined subset?"

Record the answer as a restriction another system can apply, keeping channel and purpose separate. An email request can stay limited to email when that is what the person asked for. A phone request can cover calls, SMS, or both, depending on the wording and the rule you apply. The restriction should state what must stop and what remains outside its scope.

Map destinations

List every route that could still reach the person, including sending systems, audience builders, export jobs, and any destination that receives a suppressed record.

Apply each opt-out at every sending and audience-export step, then verify every destination.³ For email and phone work, inspect the systems that can create a send, export a target, or pass a record to another sender. Ask: "Where could this person still enter an audience after the source record changes?" Each route needs an identified suppression point and an owner for the check.

Apply suppression

Place the restriction where the sending decision is made, then carry it into downstream audiences. A correct source record can still fail if an export or sending step ignores it.

Suppression lists can dynamically apply to all forms of messaging, with exceptions available for selected tags.⁴ Treat every exception as a deliberate scope decision, and check that it matches the captured request before allowing the record through. The restriction should appear in both the sending path and the audience path that can reach the person.

Verify

Check each destination after checking the originating record. A green status in the source system does not show whether an export or another sender received the same restriction.

Open each destination and confirm that the restriction arrived with its intended scope. If a destination still shows the person as sendable, stop the handoff and fix the sync or export path. Ask: "Can this destination still create an email, call, or SMS for this person?"

When Salesforce and Account Engagement share email status

When fields are shared, set an operating rule. Start with the systems that can send, then decide how their statuses should travel.

The right synchronization approach depends on where the emails are sent from.⁵ When emails are sent only from Pardot, having Pardot as the system of record should not cause issues.⁶ Salesforce can send email directly, and Account Engagement can send it as well, so syncing email preferences between the systems can help you follow email regulations.⁷

In Account Engagement, the prospect record uses the field "Opted Out". Salesforce Lead and Contact records use the field "Email Opt Out".⁸ Keep that distinction visible in the field map. "Opted Out" is separate from the older "Do Not Email" field, so changing the former to true does not change the latter.⁹

The "Opted Out" field is intended for prospects to manage their status through an unsubscribe link or an email preference center.¹⁰ Account Engagement admins need to update the Opted Out sync settings to reduce the risk of emailing people who opted out.¹¹ Use the field that matches the request and the sending path, then check the downstream destination.

Choose authority when systems can both change status

A shared status needs a clear authority rule when more than one system can receive an update. Decide this before troubleshooting a mismatch.

The sync update allows Salesforce or Account Engagement to act as the source of truth.¹² Set that choice in the configuration and document it beside the field map. Ask: "Which system is allowed to settle a disagreement when the values differ?"

Where both systems need to retain updates, Salesforce recommends creating a field in each system and referencing both values across the systems.¹³ Each system then holds its own True/False value and the True/False value from the opposite system.¹⁴ This lets the operator see where the status came from before changing the sending rule.

What not to do

These failures come from scope confusion, manual overrides, and sync rules that hide ownership.

• Account Engagement users can edit the Opted Out checkbox, but doing so is not recommended for compliance reasons.¹⁵
• Do not change opt-out synchronization behavior before checking the permissions of the "Email Opt Out" field on Lead and Contact objects.¹⁶
• Do not use the most recently updated value as the source of truth for the Opted Out field after the sync behavior change.¹⁷