Applying a suppression, end to end
A suppression is recorded once and read by the single compliance check that runs before any outreach, so it takes effect everywhere at once rather than channel by channel. Refusals are recorded with the suppression's origin. A do-not-contact entry is the strongest form, is not cleared casually, and the Connect Assistant cannot clear one at all.
The flow, stage by stage#
- Trigger — an unsubscribe request, a spam complaint, a bounce that says the address is gone, a STOP on a messaging channel, or a person adding an entry deliberately.
- User or external event — a click, a provider notification, an inbound message, or an action on a screen.
- Authentication and workspace resolution — the entry belongs to one workspace and is scoped to it; suppression is never global across tenants.
- Ingest — the recipient is identified as an address and, where the identity is known, as a person.
- Canonical record — the suppression is stored with its origin and the moment it was created, because *why* matters as much as *who*.
- Classification and reasoning — the kind of entry is fixed by its origin, not inferred: an unsubscribe, a complaint and a do-not-contact are different things.
- Knowledge, memory and rules — a block directive may exist alongside it. A block is memory tagged per channel; a suppression is compliance. They are separate mechanisms.
- Autonomy and approval — irrelevant to whether the suppression applies. An autonomous workspace is refused exactly as a supervised one is.
- Action through a provider — none when the entry is created. Its whole effect is on what is refused later.
- Result — the one compliance check that runs before any outreach now refuses this recipient.
- Relationship, timeline and memory — the entry is visible on the person, so anyone reading their record sees why nothing is being sent.
- Audit, usage and Needs You — each refusal is recorded as a decision with the suppression's origin, and no allowance is spent on a message that was never attempted.
What is refused, and what is not#
| Kind of message | After a suppression |
|---|---|
| Outreach to a prospect | Refused, with the origin recorded |
| A follow-up scheduled earlier | Refused when it falls due; the follow-up is not silently completed |
| A sequence step | Refused, and the sequence stops rather than skipping to the next step |
| A reply to someone who wrote to you | A different path with different gates — outreach and a customer reply are never merged |
| A message a person sends by hand | Passes the same boundary and the same compliance check as anything Connect sends |
The fourth row is the one people ask about, and the honest answer is that the two paths are deliberately not the same. Somebody who unsubscribed from marketing and then writes to ask a question has not asked to be ignored. Somebody on a do-not-contact entry has, and that entry is treated as the stronger statement it is.
Suppression and blocking are not the same mechanism#
- Suppression
- A compliance record about a recipient, read by the check that runs before outreach. It carries an origin and is visible on the person.
- Block
- A memory row against the contact, tagged
block:<channel>in its tags rather than written in its body, because only the tag list is read as a directive. - Why the difference matters
- A block holds across channels and across future conversations because it is memory; a suppression is a statement about permission to contact. Removing one does not remove the other.
- Deleting a thread
- Neither of the above. Deleting is a person's own mark on a conversation and blocks nobody.
When someone asks not to be contacted again, the durable answer is usually both: the compliance entry so outreach refuses, and the directive so future conversations on any channel behave the same way.
Clearing one#
Read the entry's origin before touching it.
Result An entry created by a complaint is a different situation from one a colleague added by hand, and the origin is stored for exactly this moment.
For an ordinary suppression that the person has since reversed in writing, clear it on the record.
Result Outreach becomes possible again from the next attempt onward; nothing that was refused is retried automatically.
For a do-not-contact entry, treat clearing as a deliberate act with a reason, not a tidy-up.
Result It is the strongest entry a workspace can hold and is not cleared casually.
Do not ask the Connect Assistant to clear a do-not-contact entry.
Result It cannot. The Assistant's rights are deliberately narrower than a person's, and this is one of the two places that limit is explicit.
Reading the record afterwards#
A refusal is a decision, and the decision log holds it with the suppression's origin attached. That answers the two questions asked later — *why did this person stop hearing from us* and *who decided that* — without anyone having to reconstruct it from message history.
The person's own record carries the entry too, so a colleague opening the relationship sees the reason before they write anything. That visibility is the point: a suppression that only lived inside a sending routine would be a rule nobody could see they were subject to.
Questions#
Does a suppression stop us replying to someone who emails in?
Outreach and a reply to a customer who wrote to you are separate paths with separate gates. An unsubscribe is a statement about outreach; a do-not-contact entry is the stronger statement and is treated as such.
Is a suppression per channel or per person?
It is read by one compliance check that runs before outreach on any channel, so it is not something a second channel can route around. A channel-specific instruction is a block directive, which is memory rather than compliance.
Can the Assistant add or remove one?
It can act within rights that are deliberately narrower than a person's, and clearing a do-not-contact entry is outside them. That limit exists so a conversation with an assistant cannot undo a decision a business made.