Recipe · Outbound email

Verify the list

Checks every queued address against your verification connector and records the verdict on the row. Addresses that do not exist — or that must not be mailed at all, like a spam trap — are moved to Bounced, so no touch picks them up. Run it once before the first touch; each check costs a credit on your own account, so it is written to a column rather than repeated.

On this page

What it does

Each check spends a credit on your own verification account. Needs a verification connector — without one the pack still works, unverified.

Checks every queued address against your verification connector and moves the dead ones to Bounced, so no touch ever mails them. Run it before touch 1.

It runs against one profile, through that profile's own proxy and with its own cookies — so the pages load the way that account's owner would see them. It opens no page at all, which means it can be run against a profile whose session you would rather not disturb.

One profileOpens no pageThe Outreach list table

The 8 steps

The real tree, read out of the pack the launcher ships. Indentation is nesting: the steps under a loop run once per row, and the ones under a branch run only when the condition above them holds. Every {{…}} is a value filled in at run time — from the row being walked, from a setting on the run, or from the profile itself.

loadRowsLoad the queued rowsLoad Outreach list into rows
loopEach addressLoop forEach

Each time

setVarStart this row uncheckedSet verdict
verifyEmailCheck the addressCheck {{loop.item.email}} is realon failure: continue
setVarTake the verdictSet verdicton failure: continue
saveRowsRecord the verdictSave to Outreach liston failure: continue
ifStop the dead onesIf {{vars.verdict}} equals

Yes

saveRowsMove it to BouncedSave to Outreach liston failure: continue

Each of those is one of the step types on the automation reference, with the same fields the editor shows and the same fields an agent is handed over the local API.

The tables it uses

These load with the recipe. A dataset is a typed table your workspace owns — the columns are named and typed up front so the steps can address them, and every one of them is yours to rename, extend or fill from a file afterwards.

Outreach list

readswrites

One row per person: their address, what you know about them, whether they opted in, and which touch of the sequence they are on.

email
Email · email
first_name
First name · text
company
Company · text
signal
Signal · longText
consent
Consent · select · Cold — no consent | Opted in
status
Status · select · Queued | Touch 1 sent | Touch 2 sent | Sequence finished | Replied | Unsubscribed | Bounced | Refused
touch
Touch · number
deliverable
Deliverable · select · Deliverable | Risky — catch-all | Undeliverable | Could not check
last_sent_at
Last sent at · datetime
outcome
Outcome · longText

Re-running updates the row it already wrote rather than adding a second one. That is what the match column in the save step is for, and it is the difference between a status check and a table that doubles in size every pass.

Loading it

In the launcher, open Automations, choose Load a starter pack, and pick Outbound email. Untick anything you do not want. The tables land first, then the workflows, then a project called Outbound that links them together.

What arrives is an ordinary automation row. Open it in the editor, change a step, rename it, delete it — nothing in the app treats it as special afterwards, and loading the pack a second time makes a fresh copy rather than overwriting the one you edited. Tables are the opposite: an existing table of the same name is reused and keeps its rows.