Automations - Sendrealm Documentation

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

Supported step types

{
  "trigger": {
    "event_name": "order.completed",
    "filters": {
      "amount_gte": 1000
    }
  }
}

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.

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.

Project policies can enforce event ingest limits, automation start limits, concurrent wait caps, and send action caps.
Messaging policies can enforce quiet hours, send windows, suppression precedence, unsubscribe precedence, and frequency caps.
Those same project guardrails are enforced for automation sends and broadcast sends, so quiet hours, send windows, and precedence rules behave consistently across channels.
Broadcast fanout jobs defer to the next eligible time when quiet hours or send-window rules block delivery. Automation send steps also pause and retry later for those same time-based guardrails, while permanent guardrails like suppression or frequency caps stay visible as skip reasons in the run timeline.
Those project guardrails are managed through internal backoffice controls, while the customer dashboard reflects their effects in the builder, runs, and events views.

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.

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.

Backoffice support tooling exposes automation alerts, dead letters, waiting states, run timelines, actor-tracked support actions, filtered event catalog views, redacted payload samples, and billable usage totals.
Dead-letter inspection includes the failure stage, retry count, error code, idempotency key, linked event id, and payload snapshot so support can replay or escalate with full context.
Support actions such as replaying dead letters, retrying runs, canceling runs, unblocking waits, running maintenance sweepers, and adding incident notes are actor-tracked for auditability.
Observability views include average event-processing latency and average provider-send latency so support can spot slow queues or providers before failures accumulate.

The customer dashboard includes reusable templates, the automation builder, run timelines, topics, and searchable event feed and catalog views.
Use those screens to validate event names, inspect payload shapes, review run behavior, and confirm which templates and actions your journeys depend on.