Call Opt-Out or Email Opt-Out: Preserve the Actual Request Across Channels
Preserve the person’s actual opt-out request before translating it into a multichannel stop rule. A request to stop calls, a request to stop emails, and a request to stop all outreach are different pieces of evidence. Record the wording and context, identify the person and channel, apply the intended restriction, and inspect the remaining tasks and enrollments. Do not assume that one status label automatically expresses or enforces every scope.
This is an operational state-management guide. It explains how to carry a request accurately through a workflow, rather than defining legal obligations or inferring permission for another channel. A request naming calls does not, by itself, authorize email outreach. The scope of the recorded request and the eligibility of any future action are separate decisions.
Start with the request, not the dropdown label
Capture the original message or a faithful note of the spoken request, with the time, source channel, person or address involved, and the employee who recorded it. Link to the relevant conversation or call activity where available. Retain enough context to distinguish a request about one channel from a broader request that happened to arrive through that channel.
The channel used to deliver the request does not necessarily define its scope. Someone can ask to stop all outreach during a phone call or restrict a particular address in an email response. Record what the person said rather than reducing the evidence to “call outcome” or “negative reply.”
Use Unify’s call activity and outcome workflow to retain the disposition and notes. For email, the reply review workflow lets the owner inspect the complete message and its classifications. A summary tag is useful for routing, but the underlying wording is the evidence the next reviewer needs.
Separate observed scope from implementation scope
| Request evidence | What to preserve | What still requires a decision |
|---|---|---|
| Calls are explicitly named | Exact wording, person, dialed number, and call context | Which call records, tasks, and connected dialers must reflect the restriction. |
| Emails are explicitly named | Exact wording, address, person, and email context | Which email preferences, enrollments, and connected senders require review. |
| All outreach is explicitly named | The broad wording and the identity it applies to | How to stop applicable email, call, and other outreach paths and prevent re-entry. |
| Scope is ambiguous | Original wording and the reason the reviewer cannot determine scope | An accountable human decision and a temporary hold while it is unresolved. |
| Request refers to a company or team | Who made the request and what group was described | Whether and how an account-level restriction should be represented under the organization’s process. |
These rows are review categories, not a universal product taxonomy. They also do not imply that a channel left unnamed is approved for contact. Keep “what the person requested” distinct from “what the system currently blocks” and “what the organization has decided is eligible.” A faithful record can show all three without pretending they are identical.
When a request appears broader than the available status field, do not narrow the evidence to fit the interface. Preserve the broader wording in the review record and choose an operational control that holds the relevant work while the responsible owner resolves the implementation. An inaccurate label can travel farther than the original message through a CRM sync.
Understand the documented call-specific control
Unify’s Making calls documentation names two outcomes with specific record effects: Bad number marks the dialed number invalid, while Do not call opts the person out of future calls. Those are different outcomes. An invalid phone association is a data-quality finding; a request not to call is a communication preference.
Choose the documented outcome only when it reflects the conversation. Preserve the request in the notes and inspect the person’s resulting call state. Do not use Bad number as a substitute for a call opt-out just because it also prevents an attempted call. Doing so loses the reason for the restriction and may lead a later enrichment workflow to “repair” a value that was never the actual problem.
The call documentation also says a call opt-out, invalid number, or applicable engagement policy can prevent calling. It does not establish that choosing Do not call automatically opts the person out of email, social tasks, every other application, or all future imported records. Verify those paths separately when the request requires them to stop.
Review email state and sequence state separately
Unify’s reply classifications include Opt out, meaning the person asks to stop receiving outreach. Read the full response to establish its scope. The same reply documentation says a reply can end an active enrollment according to the sequence’s ending conditions. Ending one enrollment is a workflow result; it is not automatically a complete description of a person’s preferences across all channels.
Use the enrollment view to inspect the actual outcome and any remaining work. Its troubleshooting guidance distinguishes people who opted out or are marked Do Not Email from other eligibility problems. Review the relevant preference data rather than changing it simply to make another enrollment succeed.
Inspect the ruleset settings used by each relevant sequence. Shared rulesets govern enrollment eligibility, exclusions, and other behavior; changing one affects the sequences that use it. Re-enrollment settings and simultaneous-enrollment settings solve different problems from preserving a request’s scope. A waiting period expiring does not explain away an opt-out.
Hold the appropriate work while scope is unresolved
The proposed operating rule is to hold affected outreach while the responsible owner reviews ambiguous wording, identity, or propagation. Record why the hold exists and who can resolve it. Do not silently treat an unknown scope as the narrowest possible restriction so that an automated sequence can continue.
Inspect open work through Tasks. A sequence-generated task, a one-off task, and a reply task can originate from different rules. Completing or skipping a sequence task can advance an active enrollment; it is not a general stop command. Use the operation that matches the intended state and verify that it took effect.
The task-management workflow provides a place to make the review actionable: identify the request, the systems to check, the owner, and the unresolved question. Avoid a vague follow-up task that could send another message before the scope review is complete. The task should tell the next person what decision is blocked and where the original evidence lives.
A hold is also distinct from a permanent preference. Preserve both when needed: the underlying request and the temporary operational state used while you investigate. If a reviewer later corrects an identity or implementation error, retain an explanation instead of deleting the request history or implying that the person newly authorized another channel.
Inspect every active path that could produce outreach
Build an inventory of the person’s applicable sequence enrollments, ready call tasks, manual email tasks, action-item tasks, and independent reminders. Include external dialers, sending tools, and CRM workflows your team actually uses. Limit the inventory to known systems and records; do not claim a universal stop when some paths remain unverified.
Check for multiple person records, addresses, or phone associations that may represent the same individual. Keep identity verification separate from suppression implementation. Do not spread a restriction to unrelated people simply because they share a company domain, and do not ignore a verified alternate record merely because its identifier differs.
Use the account-data maintenance workflow when the request involves an outdated employer or relationship. Preserve the original record context while you resolve the current identity. A change of title, address, or employer should not automatically erase the evidence your team already holds about a communication request.
For a company-level request or a broader account restriction, inspect the account’s actual relationships and ownership before applying a person-level workaround. The buying-committee workflow can help identify roles and relationships, but it is not proof that one employee speaks for every contact. Record the basis for the account-level decision.
Use exclusions deliberately and check which rules take precedence
Unify’s exclusions documentation distinguishes company and person exclusions. Company exclusions also apply to people associated with the matching companies. Exclusions must be enabled in the appropriate rulesets or configured through the applicable engagement policy. Creating an exclusion is not the same as confirming that every intended workflow uses it.
The exclusion setup motion illustrates how to define and inspect matching records. Adapt the approach to an approved operational restriction only when the available fields represent it accurately. Avoid using an unrelated customer or competitor field to encode an opt-out; later account maintenance could reverse the restriction without preserving its meaning.
For users assigned to engagement policies, the policy’s exclusions replace sequence ruleset exclusions. Review the person’s user context, the active policy, and whether the selected restriction warns or blocks the relevant action. A warning is not equivalent to a block, and claiming restrictions are distinct from engagement restrictions.
Exclusions continue to be evaluated for active enrollments, but the documentation describes background processing. A CRM change must reach Unify before it affects a matching exclusion. Inspect the final state; do not equate saving a source field with immediate enforcement everywhere. Turning off an exclusion also does not, by itself, start a new enrollment.
Verify the handoff to CRM and connected applications
Define which system owns the original request, which fields represent the operational state, and which integrations copy those fields. Keep the original wording or its durable reference available even when downstream applications have simpler status values. A true/false field alone cannot explain whether it came from a call-only request, an all-outreach request, or a temporary review hold.
Review Salesforce sync behavior or HubSpot sync behavior for the actual objects, fields, events, permissions, and write paths involved. An activity being logged does not establish that a preference field was updated, and a preference field arriving does not establish that a separate dialer has enforced it.
The CRM integration implementation guide provides a method for testing mappings and destination values. If using CRM chat writes, name the intended records and changes. Request a preview when required by your process, then inspect the destination. Do not authorize a broad cleanup that could overwrite the evidence or accidentally reopen eligibility.
Use a blank record and proposed acceptance checks
Capture [request reference], [received time], [recorded by], [person and identifiers], [exact wording or faithful note], [observed scope], [unresolved questions], [temporary hold], [required system states], [verified results], and [review owner]. Keep proposed changes separate from changes that have actually been confirmed.
Before relying on the workflow, use permitted test records to exercise a call-specific request, an email-specific request, an explicit broad request, and an unresolved request. These are proposed acceptance-test categories, not observed results. Check the resulting preferences, applicable enrollments, ready tasks, connected records, and attempted re-entry through the paths your team uses.
A test passes only when its predefined expected state is observed. Keep untested integrations and unresolved identity links marked unverified. Do not report global enforcement when you have only inspected one sequence. Close the operational review with the request preserved, the intended restrictions verified, and remaining limitations visible to the people who could initiate the next action.
Frequently asked questions
Does a call opt-out automatically mean email is permitted?
No. A request naming one channel does not establish permission for another. Preserve the request’s scope and evaluate any future action under the applicable organizational process.
What does Do not call do in Unify?
The Making calls documentation says Do not call opts the person out of future calls. It does not establish automatic suppression across every other channel or connected application.
Is ending one sequence the same as a global opt-out?
No. An enrollment outcome describes that sequence’s state. Inspect preference data, other active work, and connected systems before concluding that the full intended restriction is enforced.
What should happen when the request’s scope is unclear?
Preserve the original wording, assign a reviewer, and hold the affected outreach while the ambiguity is resolved. Do not silently narrow the request to keep automation running.
Do sequence exclusions and engagement-policy exclusions accumulate?
For users assigned to an engagement policy, Unify documents that the policy’s exclusions replace sequence ruleset exclusions. Verify the effective policy, selected exclusions, and whether the relevant action is warned or blocked.
