Automations

An automation lets the platform act on its own: rerun an engine when its data refreshes, start an evaluation when you deploy new code, or tell your systems when a dataset changes. On the platform each automation is a subscription: a versioned rule with a trigger (which events or which schedule), an optional condition, and one effect (what to do). Each time a subscription matches an event, Nexio records a dispatch with a stable ID and runs the effect under that ID, so a retry does not repeat an engine run or an event. A webhook post can arrive more than once, so your receiver deduplicates on the X-Nexio-Delivery header (see Effects). Subscriptions are a capability Nexio operates. Tell Nexio what you want to happen and when; Nexio writes the subscription and turns it on. There is no customer API or portal page for subscriptions. This page explains what a subscription can do so you can ask for the right one, and what guarantees apply.

​

How it works

1. A platform event is recorded, or a schedule slot comes due and the scheduler records a schedule.fired event.
2. About every 5 minutes, while your organization’s event log is in shadow or live mode, the dispatcher reads up to 500 events it has not yet evaluated, recorded in the last 24 hours and at least 30 seconds ago (so a slow commit is not missed), and matches each against your organization’s enabled subscriptions.
3. Each match goes through admission: loop check, shadow check, debounce, and budgets. The result is recorded as a dispatch, whether or not it runs.
4. An admitted dispatch is queued. A worker runs the effect, with retries on transient failure.
5. The dispatch records the outcome. Nexio operators can replay a dispatch or a whole subscription.

Allow about 5.5 minutes between an event and its dispatch: up to 5 minutes until the next pass, plus the 30 second safety window. A backlog of more than 500 events takes more than one pass. It is not a low-latency channel. For run results, use webhooks.

​

Triggers

A subscription has one trigger kind. Event trigger. Fires on events that match all of these: Schedule trigger. Fires on a repeating slot. There are no cron expressions. Each due slot records one schedule.fired event with the slot start as its dedupe key, so a slot fires once even if the scheduler runs twice. The scheduler runs about every 5 minutes.

​

Effects

Each subscription has one effect. The effect kinds are a fixed set of four, defined in code. An effect’s configuration is checked strictly when Nexio saves the subscription; an unknown field is refused. A retried dispatch keeps its dispatch ID, and each effect uses that ID so a retry does not repeat its work. The one exception is deliver_webhook: a post can reach your receiver and then be sent again when the response is lost, so your receiver deduplicates.

• run_engine uses the dispatch ID as the run’s idempotency key, so a retry finds the run it already submitted. If admission refuses the run (for example the run cap or a request limit), the dispatch fails permanently with the refusal code.
• emit_event uses the dispatch ID as the child event’s dedupe key.
• run_eval_set stamps the evaluation run with the dispatch, so a retry finds it.
• deliver_webhook can post more than once for one dispatch. Every attempt carries the dispatch ID as X-Nexio-Delivery; deduplicate on it.

A common chain: an inbound code.deployed event matches a subscription (debounced on commit_sha) that emits eval.run.requested, and a second subscription on eval.run.requested runs run_eval_set. Repeated deploy events for one commit inside the debounce window start one evaluation.

​

Dispatch states

Every match is recorded as a dispatch, including matches that do not run. This is the only place the model is defined. The four refused and skipped states run only if replayed, and do not count toward budgets or debounce windows.

​

Budgets and debounce

​

Loop refusal

An automation cannot loop forever. When a matched event has a caused_by parent (for example an event recorded by emit_event), the dispatcher walks its caused_by chain first:

• If the event has 4 or more ancestors on the chain, the match is loop_refused.
• If this same subscription emitted any ancestor of the event, the match is loop_refused (re-entry).

Both checks run before anything is queued, and the refusal is recorded with the reason.

​

Retries and automatic disable

Failures are either transient (retried) or permanent (not retried). An unclassified error is transient. For deliver_webhook, a 2xx is success; 408, 429, and any status of 500 or greater (including nonstandard codes above 599) are transient; every other code is permanent. This differs from run webhook endpoints, whose retry policy decides; see Retry policies.

​

Replay

Nexio operators can replay work, with a named reason that is recorded:

• Replay one dispatch. The dispatch is queued again under a fresh claim. It is refused while an attempt is still running.
• Replay a subscription from a date. Nexio scans every event since that date and creates a dispatch, marked is_replay, for each matching event that has no dispatch for the subscription’s current version yet. Replay matches regardless of transition cause. It follows the organization’s mode, so in shadow it records skipped_shadow. It is refused when the event log is off.

The dispatcher looks back 24 hours for new events. An event older than that is dispatched only by a replay.

​

Versions and audit

Every change to a subscription, including an automatic disable, is saved as a new version with who made it and the reason. A dispatch keeps the version it matched and runs against that version, even if the subscription changes before the dispatch runs. New subscriptions are disabled by default.

​

Limits and defaults

​

What you configure

Nothing directly. Tell Nexio the trigger you want (an event type or a schedule), the condition, and the effect. Nexio sets up the subscription and enables it. If the effect is deliver_webhook, register the endpoint first with Create webhook endpoint and send Nexio its ID.