ConceptAutomations

Automations overview

Understand how Infra One turns product events and signed webhooks into filtered, durable actions with visible run history.

An Automation connects one Trigger to one configured Action, optionally guarded by Conditions. It is organization-scoped, can be enabled or disabled independently, and records its work in Run history.

Use Automations when a repeatable event should produce a repeatable outcome without relying on a person to notice and relay it.

The execution model

  1. A product event or signed incoming webhook creates the trigger data.
  2. Conditions decide whether the event is in scope.
  3. The action validates its stored configuration against current organization state.
  4. Durable work runs outside the browser.
  5. Run history records status, time, error category, external result, and any safety instruction.

The available trigger and action choices depend on your organization, role, and enabled product surfaces.

Automation states

Enabled means matching events may execute the action. Disabled keeps the definition and history but does not process normal trigger events.

New incoming-webhook Automations start disabled. This is intentional: creation also produces a live endpoint and a one-time signing secret, so you can store credentials, send a test delivery, and review the result before enabling production traffic.

The Automation builder configured for an incoming webhook and an Agent message action. The release-announcement shape: one signed webhook, one agent task, one bound Slack channel, and payload-derived wrappers.

Why delivery is durable

External senders can retry, workers can restart, and Slack can time out after accepting a post. Infra One uses an idempotency key and a persisted delivery lifecycle to avoid treating an HTTP response as the whole story.

The important distinction is:

  • Accepted means Infra One validated and stored the request.
  • Succeeded means generation and the external post completed.
  • Failed before post can be retried safely after the cause is resolved.
  • Failed after claim requires inspecting Slack before any manual retry, because delivery may have happened.

Start with these tasks