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

# Automations

> Create event-driven journeys with templates, waits, conditions, and topic actions.

Automations are DAG-based journeys with one trigger, reusable steps, and explicit branches.

## Supported step types

* `delay`
* `condition`
* `wait_for_event`
* `send_email_template`
* `send_push_template`
* `contact_update`
* `add_to_audience`
* `remove_from_audience`
* `set_topic_subscription`

## Trigger shape

```json theme={null}
{
  "trigger": {
    "event_name": "order.completed",
    "filters": {
      "amount_gte": 1000
    }
  }
}
```

## Common journey

1. Trigger on `order.completed`
2. Send a published email template
3. Wait for `sendrealm.mail.open`
4. If the event arrives, send a push template
5. If it times out, add the contact to a follow-up audience

## Publish requirements

* Exactly one trigger
* Reachable graph
* No cycles in v1
* Published template versions only
* Valid topic, audience, domain, and push app references

## Runtime guarantees

* Automation runs are processed with at-least-once semantics.
* Step execution is protected with step-level idempotency keys so retries do not resend the same step when a send already succeeded.
* `wait_for_event` and timeout paths use run and wait locks to avoid double-resume races.
* If a worker crashes, maintenance sweepers recover stale runs, replay due events, and advance expired waits.

## Retry and timeout behavior

* Event processing retries use exponential backoff.
* Final failures move to the dead-letter queue for replay from backoffice tooling.
* `wait_for_event` timeout handling is minute-level scheduler based, so timeout execution is near the requested delay but not hard real-time.
* If a matching event arrives after the timeout branch already executed, the late event does not reopen that wait state or rerun the completed branch.

## Billing and metering

* Usage can be metered by event ingest, automation runs, wait creation, template test sends, and delivery actions.
* Plan enforcement should be treated as separate from idempotency: a retried request may deduplicate, while accepted usage still counts against the relevant quota or metered line item.

## Retention

* Runs default to 180 days of retention.
* Wait states default to 30 days of retention.
* Template and automation versions remain immutable, but project retention may archive old non-current versions that are no longer referenced by sends, runs, or broadcasts.

## Related pages

* [Automation Builder](/tutorials/automation-builder)
* [Automations API](/api-reference/endpoint/automations)
* [Automation Runs API](/api-reference/endpoint/automation-runs)