Automation Triggers

W11 draft / unreleased: The event names and safety rules below mirror the coordinated trigger adapter and graph contract. Availability still depends on the build being reviewed; this page does not claim production event delivery or provider activity.

Each workflow has one trigger. A trigger identifies both the business event and the subject that later conditions and actions may use. Choose the narrowest event that represents the workflow's starting point.

Current bridge catalog

The current guided and visual bridge exposes these trigger keys and canonical events:

The event is durable and is paired with the organization and workflow identity. Retrying the same occurrence therefore keeps one enrollment for that workflow, while the same event may intentionally enroll another eligible active workflow. The published revision is frozen when a run is enrolled.

The review.left condition is evaluated against the same customer and run, never against an arbitrary review ID in a caller-supplied payload. For a run whose exact trigger is review.submitted, the condition requires that run's matching durable outbox event. For another trigger, it considers only reviews created at or after that run's persisted start time. A missing or mismatched run fence makes review.left unavailable rather than treating an old review as a new response.

The template catalog also contains a speed-to-lead recipe that uses lead.created. Treat that as an extended graph-catalog trigger: use it only when the trigger palette in the build being reviewed exposes it. A catalog definition is not an assertion that every V1 event is enabled in the current bridge.

Change a draft trigger

When you select a different trigger type in an editable draft, Guided Editor replaces the previous trigger configuration with the valid default shape for the new event. Incompatible keys are cleared rather than carried into the new trigger. Review the new subject and settings before Save draft; an invalid configuration cannot be saved. The active published trigger and already enrolled runs remain unchanged until the new draft is activated.

Deadline triggers and canonical inbound subjects

estimate.expiring uses the current published estimate expiry and the selected location's timezone. A days_before setting subtracts calendar days from the expiry's local date while preserving its local wall-clock time. The event is eligible only at or after that calculated instant, never earlier, and only while the estimate remains unexpired. The target local day must still be the configured day when the sweep evaluates it, so a late sweep can catch a due occurrence without creating an early or post-expiry event. The producer checks these boundaries on a five-minute sweep and de-duplicates the same estimate deadline and offset.

Invoice due and overdue occurrences use the invoice party or location timezone and occur at local midnight for the configured calendar day. They do not use UTC midnight. A changed source deadline creates a new occurrence identity; a retry of the same occurrence remains one event.

The sms.received, email.received, and inbound call triggers use the canonical customer subject from the committed communication record. The record must already exist in the same organization and location. A concrete message or call cannot be turned into an automation subject by creating a synthetic customer or borrowing a record from another scope; missing, mismatched, or unverified identity is rejected.

Entry conditions

Use conditions to decide whether an eligible event enrolls the workflow. The guided editor supports All and Any logic for its bounded condition list. Graph condition nodes expose TRUE and FALSE paths and can use the same logic inside the node.

The current bridge fields are:

Use the operator shown for the selected field. Categorical, numeric, and tag operators are validated on save. A condition that refers to a field absent from the trigger subject fails safely instead of using a value from another record. If required data is unavailable at run time, the condition remains visibly retryable and does not take the FALSE edge from missing data.

Manual enrollment

Manual enrollment is an explicit operator action for an active workflow. The server checks the actor's Automations manage permission, organization and location scope, selected active revision, subject eligibility, and duplicate run state before queuing it. Repeating the same request keeps one enrollment. Manual enrollment does not turn a workflow into a broadcast or enroll the whole customer database.

Trigger safety

One workflow revision owns its trigger, conditions, and actions. Saving a new draft does not alter the trigger of an active revision, and activating a draft does not rewrite runs already in progress. There is no recurring-schedule trigger in the W11 contract; use a supported business event or an explicit manual enrollment instead.