Sending safety
Sequence work keeps publishing, enrolling, starting, delivery, and replies separate.
Sending safety keeps sequence design separate from outward delivery. Use it when you are building a Sequence, selecting people for Enrollment, checking a Sender, or investigating why a person did not receive a message.
The Sequences and enrollment page explains the sequence lifecycle, while Senders and mailboxes explains the identity, health, rotation, and policy behind delivery. For a workspace-wide exclusion, use Do not contact.
Separate the lifecycle
A sequence moves through distinct states: drafted, validated, published, enrolled, started, delivered, and replied. Building the sequence does not wait for a LinkedIn or email account. A missing account blocks the relevant send step, not the ability to draft or validate the plan.
Publishing and enrolling do not send. An explicit start is the event that begins delivery. This distinction lets you review the audience, steps, channel, and sender policy before any person is contacted, and it lets a team prepare the full system even while a connection is unavailable.
Each channel shares one contact history. Email and LinkedIn messages for the same person belong in one sequence, one view, and one launch. A channel is not a route around a stop in another channel.
| State | What happens | Delivery result |
|---|---|---|
| Drafted | The sequence and its steps are being prepared. | No delivery occurs. |
| Validated | The sequence is checked before it is used. | No delivery occurs. |
| Published | The sequence definition is made available for use. | No delivery occurs. |
| Enrolled | A person is included in the sequence. | No delivery occurs. |
| Started | The sequence is explicitly started. | Outbound delivery can begin. |
| Replied | A person has responded. | That person's run ends. |
Check the recipient before delivery
Before starting a sequence, inspect the selected rows, the recipient data needed by each step, and the current do-not-contact ledger. The sender policy can block a recipient with suppressed_or_do_not_contact, and the enrollment result identifies the blocked channel as email or LinkedIn.
A reply, bounce, unsubscribe, suppression, decline, wrong-person response, or finished conversation ends outreach to that person on every channel. Do not use another sender, another sequence, or another channel to continue contact after one of those outcomes.
Existing conversations are handled in the existing conversation. Read the whole thread before drafting a response. If the person asks to unsubscribe or declines, do not pitch and confirm that the relevant suppression is present.
Company pause on reply can apply when several people work at one company. Treat it as a reason to inspect the company context and active outreach before extending a campaign to another contact.
Check sender policy and capacity
The senders pack owns suppression, do-not-contact rules, mailbox health, rotation, sender identities, sending domains, and sender policy. The sequence pack owns the sequence, cadence steps, templates, sends, reminders, follow-ups, and lifecycle state. Keep those responsibilities separate when you investigate a delivery issue.
Before a live start, look at sender health, sending hours, cooldowns, daily caps, suppressions, and remaining headroom. Sends spread over days rather than minutes. A capped cell or delayed send is pacing, not a failure, so read the sender state before changing a sequence step.
Missing sender information produces a specific blocker. A missing email means the row lacks the email data for an email step. A missing LinkedIn URL means the row lacks the URL for a LinkedIn step. No connected sender means the channel lacks a usable sender connection.
Build and review without starting
Architect can build a sequence from the requested audience and outcome, then show the selected steps and sender constraints. It uses the outreach skill for sequence practice and the available capability contract for the exact action. The skill teaches the work but grants no tool authority.
Ask for a validation or a dry run when you need to inspect a plan against current workspace state without business writes, provider spend, or outward actions. Every mutating call names a Mode; the server never defaults a mutation to live.
A useful review has the recipient set, the intended channel, the sender identity, the sequence step order, suppression results, and the state that will start delivery. The app records outcome totals including enrolled, active, sent, replied, meetings, bounced, unsubscribed, and failed.
Validate this sequence, its selected recipients, sender policy, and do not contact results. Do not start delivery. Show every blocker and the channel it affects.When it goes wrong
If a result contains suppressed_or_do_not_contact, list the matching suppression entries and verify the recipient identity. Keep that person out of future outreach; changing a channel does not bypass the stop.
If a result contains no_connected_sender, connect or select a sender for the affected channel. If it contains missing_email or missing_linkedin_url, correct the recipient data. Those conditions block sending, but they do not block building the rest of the sequence.
If the send result is unclear, read the current conversation before retrying. A conversation status does not prove delivery. If a person replied, bounced, declined, or unsubscribed, their run has ended, so investigate the stop rather than re-enrolling them.
If delivery is delayed, inspect caps, cooldowns, sending hours, and headroom. Do not treat paced delivery as a reason to create duplicate recipients or add another sender for the same person.
If a sequence was published or people were enrolled but nothing was sent, inspect whether an explicit start happened. Those earlier lifecycle states intentionally do not create delivery. Record the state you found, then correct the missing setup or data and validate again before a live start. Keep the evidence with the sequence rather than relying on a memory of the last run.