> ## Documentation Index
> Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How a workflow's sends are scheduled

> Why a send waits, from a busy email account to a holiday, and how long the workflow keeps trying before it gives up.

export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => {
  const src = `/images/screenshots/${lang}/${id}.png`;
  const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai';
  return <figure className={`pl-shot pl-shot--${frame} not-prose`}>
      <div className="pl-shot__frame">
        {frame !== 'bare' && <div className="pl-shot__bar">
            <span className="pl-shot__dots">
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
              <span className="pl-shot__dot" />
            </span>
            <span className="pl-shot__url">{chrome}</span>
          </div>}
        <div className="pl-shot__media">
          <img src={src} alt={alt} loading="lazy" />
          {marks.map(mark => <span key={mark.n} className="pl-shot__mark" style={{
    left: `${mark.x}%`,
    top: `${mark.y}%`
  }} aria-hidden="true">
              {mark.n}
            </span>)}
        </div>
      </div>
      {caption && <figcaption className="pl-shot__caption">{caption}</figcaption>}
    </figure>;
};

When a workflow reaches a block that sends an email, a WhatsApp message or an Instagram DM, it resolves a connected account before it writes a word. If that account cannot be used right now, the block does not fail: it holds the run there, checks again on its own, and only stops after a bounded number of checks.

<div className="pl-availability">
  <div className="pl-availability__row">
    <div className="pl-availability__label">Where</div>
    <div className="pl-availability__value"><span className="pl-path">Outreach<span className="pl-path__sep">→</span>Workflows</span></div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">Your role needs</div>
    <div className="pl-availability__value">Read access to Workflows <code>read-workflows</code>. Admin, Member and Viewer have it by default.</div>
  </div>

  <div className="pl-availability__row">
    <div className="pl-availability__label">To create or change</div>
    <div className="pl-availability__value"><code>create-workflows</code> to add one, <code>update-workflows</code> to change one, on top of the permission above.</div>
  </div>

  <div className="pl-availability__note">If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.</div>
</div>

This is separate from a **Wait / Delay** block you add to the canvas by hand. It is built into **Send Email**, **Send Follow-up**, **Send Reply**, **Send WhatsApp** and **Send Instagram DM**, whether or not your canvas has a wait block anywhere near it. LinkedIn action blocks never hold a run this way: they queue the action and their own jobs decide when it goes out, which is covered in [LinkedIn action limits, schedule and ramp-up](/en/channels/linkedin-limits-and-ramp-up).

## How it behaves

### A send picks one email account and then sticks to it

Leave a **Send Email**, **Send Follow-up** or **Send Reply** block on its automatic account option and the workflow resolves an account itself, the first time that run reaches one of those blocks, then pins the choice to the lead's enrollment. Every later automatic send in the same run starts from that pin, so a multi-step conversation stays on one mailbox. The option is worded as a rotation ("Auto · rotate across all senders"), and that is what it means across your campaigns; inside a single run there is no rotation.

A block where you picked one specific email account always uses that account and is never swapped for another. If that account has been archived or deleted, the run stops there instead of moving to a different mailbox.

**Send Follow-up** and **Send Reply** look at the lead before they look at the pin: they prefer the account on the lead's most recent message, sent or received, from a workflow or a campaign. Normally that is the pinned account. When it is not, because a campaign wrote to the lead from another mailbox in between, the run continues on that mailbox and pins it instead, which is what keeps a reply inside the conversation the lead is actually reading.

The pin only moves when the pinned account is gone: archived, deleted, [paused or in an error state](/en/email-accounts/sender-statuses). It does not move because the account is resting, over its daily limit or outside its sending window. Those read as "come back later", not "pick someone else".

### When no account has room, the run waits and rechecks

An account has room when it is Active, fully set up, inside one of today's sending windows, under its [daily limit](/en/email-accounts/smart-daily-limit), and past the minimum gap since its last email. A mailbox that is still being provisioned is not a candidate at all.

If nothing qualifies, the enrollment's status becomes **Waiting** and the block rechecks after a randomized delay rather than a fixed one, so a batch of held sends does not retry on identical offsets and read as automated. It keeps doing that until the 240th check, which is long enough to outlast a normal week including a weekend. A wait does not count as a step, so the workflow's own step ceiling never ends one of these; only the ceilings in the table below do.

The lead's page shows both halves of that: the status pill, and the time the run resumes.

<Screenshot id="workflows/how-sends-are-scheduled--waiting-step" url="/leads/prospects/187" alt="A workflow enrollment card on a lead's page showing a Waiting status pill, the step the run sits on, and a line saying when it resumes, with the journey expanded underneath" caption="The resume time is on the card itself, and again on the journey's current step." />

You can see the other side of the same question on Email Accounts. The calendar icon on a mailbox's row opens today's schedule: the times that account is set to send today, drawn on a 24-hour clock and listed beside it, with the next one marked.

<Screenshot id="workflows/how-sends-are-scheduled--sender-schedule" frame="bare" alt="The schedule panel for one email account: today's send times as dots on a 24-hour clock face on the left, and the same times listed on the right with the next one highlighted" caption="This is the account's working day. A send that lands outside it is not sent late: it waits and keeps checking until the account is open again." />

### Replies skip the throttles

A **Send Reply** block only ever answers a lead who already wrote in, so it is treated as reactive rather than outreach. It ignores resting days, the daily limit, the sending window and [national holidays](/en/leads/holidays-and-out-of-office). All it asks is that the email account it would use is Active and not archived.

There is one way a reply still waits: if the block names one specific account by hand and that account is paused or in an error state, the block waits for it rather than answering from another mailbox. On the automatic option it simply moves to an Active account.

**Send Follow-up** and **Send Email** get no exemption. A scheduled follow-up waits exactly as a first outreach email does.

### A resting mailbox and a holiday lead wait for tomorrow

Two things hold a send until the next day instead of rechecking through the same day, and both resume at a jittered time the following morning rather than on the hour:

* The account is [resting today](/en/email-accounts/resting-days-and-schedule). If the run is already pinned to that account it waits for it; with nothing pinned yet, it waits only when every account it could pick is resting. On Email Accounts, a resting mailbox carries a **Resting today** chip.
* The lead's own country is on a national holiday. A lookup that fails, or that cannot resolve the lead's country, is read as "not a holiday", so outbound is never held by an inconclusive answer.

The account is resolved before the holiday is checked, so a resting mailbox holds the send first and the holiday question is never reached that day.

Each of these keeps its own count and stops at the 14th check. Since each wait is roughly a day, that ceiling is about two weeks.

### When a wait runs out, the run ends as Completed

None of these ceilings produce a **Failed** enrollment. When a bounded wait is exhausted, and immediately when the workspace has no Active email account to wait for at all, the block stops the run: the status becomes **Completed**, the same status a run that reached its last block on purpose shows. The journey's closing marker says the run reached the end, in those words, either way.

<Warning>
  Nothing on the enrollment card or its journey names which of these stopped a run. A **Completed** enrollment is not proof that every block in it sent: check the lead's journey, and your email accounts' schedules and daily limits, before assuming it went as planned.
</Warning>

### Chat blocks wait the same way, with their own ceilings

**Send WhatsApp** and **Send Instagram DM** resolve an account and a recipient before generating any content, for the same reason email sends resolve an account first: a wait should not spend a content-generation call on a message that is not going out yet.

WhatsApp is the one that waits inside the workflow. If the account is over its message budget the block rechecks until the 96th check. If the account's sending window is closed it waits for the exact moment that window next opens, rather than polling for it, with a small fixed number of those waits as a backstop against a broken schedule. A WhatsApp message to a lead who wrote to you recently is not held for the window at all.

Instagram's budget is enforced inside its own send job, after the block has already handed the message over, so a **Send Instagram DM** block never sits in **Waiting** for budget the way a WhatsApp one can.

### The message exists before anyone sends it

Once an email account is available, the workflow does not send the email itself. It writes the message and saves it with the status **Scheduled**. A recurring pass picks up scheduled messages whose send time has arrived and hands each one to the same send job a campaign email goes through, so what leaves your mailbox is a saved row rather than something the workflow fired and forgot. If the lead is marked out of office when that pass reaches the message, the message is pushed past the lead's return date instead of being sent.

A **Send Reply** block set to save as a draft writes the row as **Draft** instead, and that pass never picks a draft up. See [Scheduled, draft and failed messages](/en/inbox/scheduled-drafts-and-message-statuses) for what each status lets you do to a message.

Workflow messages carry no campaign, so a campaign's report, which only ever counts its own messages, never includes them.

Chat blocks follow the same order: the message row is written and saved first, and only then is the job that delivers it queued.

## Limits

| What holds the send                                                                                                   | How it waits                               | Ceiling                        | At the ceiling                         |
| --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------ | -------------------------------------- |
| No email account has room (sending window, daily limit or the gap since its last email)                               | Rechecks after a randomized delay          | 240 checks                     | Run ends, status Completed             |
| A **Send Email** block finds another first outbound to the same lead already in flight, from a workflow or a campaign | Rechecks after a few minutes               | 240 checks, counted separately | Run ends, status Completed             |
| The account the run is pinned to is resting today, or every account it could pick is                                  | Waits until the next morning               | 14 checks                      | Run ends, status Completed             |
| The lead's country is on a national holiday                                                                           | Waits until the next morning, once a day   | 14 checks                      | Run ends, status Completed             |
| The workspace has no Active email account at all                                                                      | Does not wait                              | None                           | Run ends immediately, status Completed |
| The one account a block names is archived or gone                                                                     | Does not wait                              | None                           | Run ends immediately, status Completed |
| A WhatsApp account is over its message budget                                                                         | Rechecks after a randomized delay          | 96 checks                      | Run ends, status Completed             |
| A WhatsApp account's sending window is closed                                                                         | Waits for the moment the window next opens | A small fixed number of waits  | Run ends, status Completed             |
| A **Send Reply** block with an Active email account available                                                         | Does not wait on the rows above            | None                           | Writes the reply straight away         |

## Related

<CardGroup cols={2}>
  <Card title="Workflow troubleshooting" icon="circle-question-mark" href="/en/workflows/troubleshooting">
    Start here when a run stopped, or never moved, somewhere you didn't expect.
  </Card>

  <Card title="Resting days, sending windows and deferrals" icon="calendar-clock" href="/en/email-accounts/resting-days-and-schedule">
    Every reason a healthy email account might not send today, explained on its own.
  </Card>

  <Card title="National holidays and out-of-office pauses" icon="calendar-x" href="/en/leads/holidays-and-out-of-office">
    Why outbound to one lead pauses while the rest of your outreach keeps going.
  </Card>

  <Card title="Scheduled, draft and failed messages" icon="clock" href="/en/inbox/scheduled-drafts-and-message-statuses">
    What the Scheduled and Draft chips mean, and what you can still do before a message sends.
  </Card>
</CardGroup>