Suppression Lists
One roll of addresses per workspace that nothing may go to. It gets consulted twice over: once when somebody is put onto a cadence, and again in the instant after the send has claimed its place.
One roll, read at the door and again at the step
not on the roll- p.raman@northgate.co.ukmanualfrom the screen
- ops@harlowfreight.commanualfrom the screen
- j.okafor@vellum.iomanualfrom the screen
- B.Osei@meridian-log.commanualfrom the screen
- At the doorbefore a run existsNot on the roll. A run is created.
- At the stepafter the claim is takenClaim taken, roll read, nothing found. The message renders and the walk carries on.
Product figures from the platform’s own defaults - not customer averages
How it works.
Held once, keyed on the address
The address is the unique key, so it cannot appear twice and somebody who moves to a new address is no longer covered by the old row. A reason and a source travel alongside, which is how you tell a hand-entered block from an automatic one.
Checked at the door, and again at the step
Adding somebody to a cadence looks up their address first and refuses quietly if it is on the roll. The send path looks a second time after taking its claim, marks that claim failed, and halts the walk with the reason recorded. Anyone holding no address at all is admitted without complaint and then stopped at the first message.
Two ways on, and one of them needs nobody
The screen takes an address and files it as manual. A hard failure notice coming back is parsed as it arrives, the address is filed as bounced, and everyone currently on it is closed out. So the roll grows from what the receiving servers tell you as well as from what you type.
It stops the cadence; it does not edit the person
The run closes marked suppressed. The record itself is left alone: no flag is set on it, no tag written, and the do-not-call marks the phone side works from are an entirely separate thing.
Two moments in every run.
Every run passes through the same seven. Suppression Lists is the lit ones, and everything either side of it is a different page in this category.
- 01Trigger
the thing that happened first
- 02Enrol
how somebody gets onto it
- 03Wait
the pause, and what governs its length
- 04Branch
the fork, and which side is taken
- 05Act
the mail, the text, the task that goes out
- 06Measure
what counts as it having worked
- 07Exit
how somebody comes off it
The specifics.
8 facts- Key
- The address. One row per address across the entire workspace
- Reasons the column describes
- Bounced, manual, replied, complained. That list is a comment beside the column rather than anything the database enforces
- Reasons written in practice
- Manual from the screen, and bounced from a hard failure notice the moment one comes back
- Consulted at
- The moment somebody is added, and again inside the send after the claim is taken
- Capitalisation
- Compared exactly as stored. The same address filed differently cased is a second row
- The screen
- Newest five hundred rows. No search field and no paging beyond them
- Removing one
- Delete the row and that address can be written to again. Runs already closed stay closed
- Not the same as
- This is email only. Do-not-call on a record is a separate roll the dialler reads
What starts this, and what it starts.
Automation is only ever a middle. These are the things that set it running and the things that run because of it.
More in Automation & Flows
13 capabilitiesSequences, dispositions and webhooks that act without being asked.
Thirteen node kinds on a canvas: send, wait, branch on behaviour, split, call task, tag, goal. Publish a version and in-flight leads keep their own place.
A unique URL per integration with HMAC signing, rate limits, payload caps and idempotency - plus a log of every delivery it ever accepted or refused.
Branch on whether they opened, clicked or replied, and on how the last call was dispositioned - so the next step answers what actually happened.
Weighted splits assigned by a deterministic hash of the enrolment, so a lead always takes the same arm no matter how often that step is run again.
Hold a lead for minutes or days between steps, clamped to the sending window you set, so that an overnight wait never lands at four in the morning.
Drop a call step into a sequence and it raises an assigned task on the lead's owner, with the outcome the rep logs coming back as a branchable answer.
Name a linked deal as the outcome that means the sequence worked. Reaching it stamps goal met on the run and takes the branch you wired behind it.
Twenty-six behaviours attach to wrap-up codes, and twenty codes ship already pointing at one, so ending a call the right way books the follow-up.
Six event types a CRM rule fires from: stage change, field update, new record, reassignment, schedule and inactivity, agreed in four places at once.
Send the email, assign the owner, raise the task, set the field, move the stage or call a webhook. Six modules, run in the order you stored them.
Eight comparison operators guarding each action, combined with AND and only AND, so a rule meaning either of two things is built twice, as two rules.
A text is a step on the same canvas as the email and the call task, written into the real thread and carried out by the number it is going out from.
A versioned path, a key minted once and kept as a hash, and the same role and profile model the interface runs on deciding what that key may touch.
The rest of the platform.
Five more categories, all on the same record and the same bill. Each card names three of its capabilities, so you can tell from here whether it is worth opening.
Automation & Flows
See suppression lists on your own floor.
Thirty minutes, your numbers and your data. We will set suppression lists up live and you can decide from the thing itself rather than from this page.
14-day trial · no card · migration included