Send a personalized email to the current subscriber. Workflow gives every `EMAIL` step a dedicated internal campaign owned by that exact workflow and step.

## Workflow ownership

- Internal emails use campaign `type: WORKFLOW` and do not appear as broadcast campaigns.
- One internal campaign belongs to one workflow step.
- A broadcast campaign or another step's email is duplicated instead of linked directly.
- Deleting or replacing a step cleans up internal campaigns that are no longer referenced by any preserved version.
- Published versions preserve the email references used by existing runs.

When an agent creates or changes an email, it provides complete inline content to `configure_workflow_draft`. Lumail resolves the owned `campaignId` in the same transaction.

```json
{
  "id": "email-welcome",
  "type": "EMAIL",
  "name": "Welcome",
  "email": {
    "subject": "Welcome aboard",
    "preview": "Your first steps",
    "senderId": "sender-id",
    "replyTo": "support@example.com",
    "content": {
      "type": "doc",
      "content": [
        {
          "type": "paragraph",
          "content": [{ "type": "text", "text": "Welcome!" }]
        }
      ]
    }
  }
}
```

Never use `create_campaign` for a Workflow email. After configuration, read and render every ID returned in `configuredEmails`.

## Behavior

- Fetches fresh subscriber data before sending
- Skips if subscriber unsubscribed (workflow continues)
- Fails validation when a required owned campaign reference is missing
- Fails if email limit reached

## Duplicate Prevention

Each subscriber receives each campaign only once by default.

With **Allow Repeats** enabled, the subscriber can start another run after `repeatCooldownMinutes`. Delivery deduplication remains scoped to the run and step so retries do not duplicate accepted sends.

## Sending Queue

Workflow emails are **queued exactly like campaigns**. Each email step is backed by a
campaign behind the scenes, so its emails:

- Use the **bulk lane**, the same one regular campaigns use. Only transactional emails
  (login codes, notifications) and campaign test emails get instant priority.
- Join your organization's **single sending queue**, in **first in, first out** order.

This means a workflow email queued while a large campaign is already sending waits for that
campaign to finish draining before it goes out. Workflow emails are not prioritized over
campaigns, and campaigns are not prioritized over workflow emails.

Two consequences worth planning around:

- **Avoid launching a large campaign during peak workflow activity** if the workflow email
  is time-critical (welcome email, purchase confirmation sequence).
- **Sending is never lost when the queue is busy** — emails wait their turn, and each
  recipient is tracked individually so a retry never causes a duplicate.

If sending is suspended (monthly quota reached or plan suspension), the workflow run is
**paused** rather than failed, and resumes automatically once sending is active again.

## Verification

For every internal workflow email:

1. Read it with `get_campaign`.
2. Compare sender, subject, preview, reply-to, and TipTap content.
3. Render it with `render_campaign`.
4. Require non-empty HTML and text plus `hasUnsubscribeLink: true`.
5. Confirm `list_campaigns` does not expose it as a broadcast.

See [Email Sending Queue](/docs/features/email-sending-queue) for the full picture,
including how capacity is shared between organizations and plans.

## Related Documentation

- [Email Sending Queue](/docs/features/email-sending-queue) - How campaigns and workflow emails share the queue

- [Send Email API](/docs/api-reference/api-emails-send) - Send emails outside workflows
- [Variables](/docs/features/variables) - Personalize email content
- [Tag Action Links](/docs/features/tag-action-links) - Add one-click tag actions in email links
- [Content Deliverability](/docs/features/content-deliverability) - Optimize email content for inbox placement
- [Subscriber Events](/docs/features/subscriber-events) - View email delivery events