Hi @Gavin5656
According to this:
- **Full audit trail**: Every run records inputs, outputs, errors, duration, and initiator (user, system, AI, webhook) at each step
- **Run Explorer**: Backoffice UI for investigating runs — filterable list, visual replay on the canvas, step-by-step data inspection
- **Draft/publish lifecycle**: Automations follow Umbraco's content model — draft, published, inactive. Version history with rollback. In-flight runs complete on the version they started with.
- **Access control**: Leverages Umbraco's existing user group/permission model
- **Failure notifications**: Configurable channels (email, webhook) per automation
- **Safety**: Rate limiting, kill switch (global + per-automation), timeout enforcement, trigger deduplication
---
## Load Balancing
Works out of the box in load-balanced Umbraco environments:
| Deployment | How it works |
|-----------|-------------|
| **Single node** | In-memory message transport. Zero external infrastructure. |
| **Multi-node** | All nodes poll the shared outbox table. Optimistic concurrency ensures exactly-once consumption. All nodes participate in trigger processing and step execution. |
Only scheduled (CRON) triggers are restricted to the SchedulingPublisher node. Everything else runs on any node.
Automate handles it itself. Scheduled triggers run on the SchedulingPublisher node, and everything else runs on any node but goes via a shared outbox table with optimistic concurrency, so you get exactly-once consumption across the cluster. No duplicate runs and no need for your own IServerRoleAccessor guard.
Researched with the help of AI.
Justin