Triggers, conditions, and actions

Every Automation answers three questions:

1. What happened? — Trigger
2. Should this definition react? — Conditions
3. What should happen next? — Action

Trigger

The trigger creates an event object. Product triggers describe changes inside Infra One. Incoming webhook accepts an external JSON object after signature, timestamp, size, and idempotency validation.

Choose the narrowest trigger that represents the source event. Do not use conditions to reconstruct a trigger that already exists.

Conditions

Conditions filter trigger data before action execution. Add a condition when the same trigger should produce different outcomes for different values.

An empty condition list means every valid event of that trigger type is eligible. A condition is not a substitute for authorization: the Automation and its action still validate organization-scoped records and current configuration.

Action

The action owns the durable side effect. Its fields are stored with the Automation, and references such as an agent or Slack channel are reloaded and validated when the action runs.

This prevents an old definition from silently using a retired agent, a channel from another organization, or a disabled Automation.

Definition time versus run time

At definition time, the form limits choices to records you can currently use. At run time, Infra One checks again:

• the Automation is enabled, except for an explicit test delivery;
• the action is enabled and valid;
• referenced records still exist in the same organization;
• a selected agent is enabled;
• a selected Slack channel is enabled and bound to that agent;
• payload mappings resolve to valid strings.

Configuration drift therefore becomes a visible failed run instead of an unsafe best guess.

One event, one durable identity

For incoming webhooks, the sender supplies an Idempotency-Key. Within an endpoint, that key names one logical delivery:

• the same key and identical raw body return the original delivery;
• the same key with a changed body conflicts;
• a new logical event requires a new stable key.

The release playbook uses allocator-one-prod-v1.4.379: repository, environment, and release version together describe the event.