Every `send` step in a workflow goes through the **same pipeline as a [Broadcast](/sending-email/broadcasts)**: your connected SES account, the deployed template, per-contact merge data from attributes, and one-click List-Unsubscribe headers. The difference is timing — a workflow send fires when a contact reaches that step, not all at once.

## Consent is re-checked at send time

Consent for the send's topic is re-evaluated **at the moment of each send**. A contact who unsubscribes mid-journey is quietly skipped for that send while their journey continues — they simply don't receive that email.

## Send window

`send window 9am-6pm in contact timezone` defers any send that comes due outside the window to the next in-window moment, using each contact's `timezone` attribute (falling back to the org default). A step that comes due at 3am waits until 9am.

## Frequency cap

A **frequency cap** limits how many drip emails a single contact receives in a period. Capped sends are **skipped, not queued** — the journey moves on. Two levels apply:

- **Org-wide default** — enabled by default, adjustable in your workspace settings. Applies to every workflow that doesn't declare its own cap.
- **Per-workflow override** — a workflow can set its own `frequency cap <N> per <duration>` (e.g. `frequency cap 4 per 7 days`), or `frequency cap off` to exempt itself entirely. A workflow-level cap **replaces** the org default for that workflow — its own threshold and window are used instead, not in addition. The count being compared is still **cross-workflow**: a send from this workflow counts against, and alongside, sends from every other workflow to the same contact — only the threshold and window are workflow-specific. Set it in the workflow's **Flow settings** panel (managed workflows) or directly in the `.flow` source (git-backed workflows) — see the [SendFlow reference](/workflows/flow-reference#settings-before-any-step).


  Unlike the topic tier, the frequency cap is **not** exempt for `transactional` sends — a capped-out contact skips a transactional step exactly like a marketing one. If a lifecycle workflow (e.g. onboarding nudges) must never be capped, give it its own `frequency cap off`. See [Consent & lifecycle mail](/sending-email/consent-and-lifecycle#two-consent-lanes-marketing-and-transactional) for the full tier breakdown.


## Dry run

From the detail page you can **dry-run** any contact through the current definition. Every condition is evaluated against that contact's real data so you see exactly which path they'd take — but nothing is sent and nothing is written. Use it to sanity-check a workflow before activating.

## Manual send approval

For workflows where a human should sign off before mail goes out, turn on **Hold sends for approval**. This is an operational switch — it takes effect immediately, doesn't create a new version, and works on git-backed workflows too.

When it's on, every send that comes due enters an **awaiting approval** state instead of sending. Held sends collect in the workflow's **Approvals** panel, where you can act on one row or several at once:

| Action | Effect |
|---|---|
| **Approve** | Send now — still honoring the send window, consent, and frequency cap |
| **Skip** | Don't send this email; the contact's journey continues to the next step |
| **Cancel** | Don't send; end this contact's journey |


  Workflows with sends waiting on you show an amber count badge — on the workflows list and on the workflow's own detail header — so held sends never sit unnoticed.


Turning the hold off lets due sends resume flowing automatically; anything already waiting stays in the Approvals panel until you clear it.