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.

Family	Current trigger labels
Contacts	Contact created, Contact updated, Added to group, Removed from group
Applications and Forms	Application status changed, Form submitted
Dealflow	Deal created, Deal stage changed
Opportunities	Opportunity created, Opportunity stage changed, Opportunity closed
Investments	Investment signed, Investment executed
External systems	Incoming webhook

Available choices depend on the organization, the viewer, and enabled product access. Application status changed is restricted to the configured administrative application context. Forms and Dealflow choices require the Dealflow service or its per-user access path.

Conditions

Conditions filter trigger data before action execution. Add a condition when the same trigger should produce different outcomes for different values. All conditions must match: conditions use AND, not OR.

The five current operator labels are equals, does not equal, contains, is one of, and is not one of. The fields and valid operators depend on the Trigger. List operators require one or more comma-separated values in the editor; save-time validation rejects unknown fields, unsupported operators, empty lists, and invalid identifiers.

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.

Actions

The current editor configures one action per Automation. It offers six action types:

Action	Outcome
Sync to group	Add or move the trigger contact in a selected group, with an optional fixed or mapped status.
Remove from group	Remove the trigger contact from the selected group.
Update contact	The executor can apply a stored field-update map, but the current editor does not collect that map; a newly created definition fails before changing a contact.
Create deal	Create one Dealflow deal from a form submission in the selected stage.
Move opportunity card	The executor can move confirmed linked opportunities to the first committed or won column, but the current editor does not collect the required target kind; a newly created definition fails before moving a card.
Agent message	Ask an enabled organization agent to compose and post one message to its enabled, bound Slack channel.

Do not select Update contact or Move opportunity card in a new definition until those editor controls are repaired. Both choices are visible, but an editor-created definition lacks required action configuration and fails before applying the mutation.

The action owns the durable side effect. Its fields are stored with the Automation, and references such as a group, stage, agent, or Slack channel are resolved when the action runs. Create deal appears only when Dealflow access is available, and Agent message is valid only with Incoming webhook.

For Agent message, run-time revalidation prevents an old definition from silently using a retired agent or an invalid channel binding.

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;
• stored references and required configuration still resolve;
• 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.

Access

Automations currently reuse Contacts capabilities at their route and mutation boundaries. The view_contacts capability allows you to browse the Automations list and detail pages. The manage_contacts capability is required to create, edit, enable, disable, delete, test, retry, or otherwise mutate an Automation. A Condition is a data filter, not an authorization boundary.

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.