Build an automation

Automations are Business features. The workflow definition, event payloads, checkpoints and run history stay in your Cloudflare Runtime; delays do not keep a request or process open.

Before you start

Deploy a healthy Runtime, verify the sending domain, create a production template or provide message content, and create an active subscription topic before sending subscription email. Open Automations, select New automation, then choose a stable ID, name and trigger event such as user.created.

Build the workflow

Add and reorder nodes on the visual canvas. A workflow must contain 1–100 steps and its complete JSON definition must be no larger than 64 KiB.

Send

• From must be an address on a verified domain.
• To accepts one address, a comma-separated list, or payload variables such as {{user.email}}; one step accepts at most 50 recipients.
• Use a production template ID, or provide text/HTML content. Template variables come from the event payload.
• transactional is the normal class. For subscription, select an active subscriptionTopicId; the Runtime then enforces the recipient’s preference.
• The Runtime uses workflow-{runId}-{step} as the idempotency key, so replaying the same checkpoint cannot send a second copy.

Delay

Enter 1–525,600 minutes. The Runtime stores nextRunAt in D1 and marks the run waiting. Its scheduled trigger resumes due work; neither the browser nor CFsend control plane needs to remain online.

Condition

Enter a payload field path such as user.activated, the expected value, and how many following steps to skip when false. The expected value is parsed as JSON when valid, so true, 42 and null are typed values. The field path is limited to 160 characters and skip cannot be negative.

Webhook

Enter a public HTTPS URL. The Runtime POSTs { workflowId, runId, payload, state }, adds an Idempotency-Key, and waits up to 10 seconds. Private addresses and plain HTTP are rejected.

Save, test and publish

1. Save draft while editing. Draft workflows never match production events.
2. Use Trigger test event with a unique event key and realistic JSON payload.
3. Inspect Recent runs and the resulting email/log entry.
4. Select Publish to set the workflow to active.
5. Use Pause to stop accepting and advancing runs. Publish again to resume.

Every save creates a new immutable version number. An accepted run keeps the definition and version it started with, so later edits cannot alter work already in progress.

Status and failure behavior

Workflow states are draft, active and paused. Run states are queued, waiting, completed and failed. A failed Send or Webhook step stores the exact error and does not advance automatically; correct the cause, then emit a new event with a new event key. You cannot delete a workflow while it has queued, running or waiting runs; the API returns 409 workflow_has_active_runs.

Use Automation events and runs for the event API, idempotency and run diagnostics. Use Subscription email before publishing lifecycle or marketing journeys.