An automation is Jetstack's configurable workflow and business logic surface. It stores trigger configuration, variables, serialized action content, draft state, execution counters, role restrictions, and trigger-aware runtime behavior.
Automations are where the platform stops being only a configured data application and becomes a working process system.
They are used for:
Jetstack distinguishes these main automation roles:
The role does not change the automation engine itself, but it strongly affects how the automation is expected to be used and understood.
automation_namedescriptiontrigger_previewrestricted_to_rolesis_activetriggervariablescontenttrigger_draftvariables_draftcontent_draftdraft_savedlast_runrun_countAutomations are driven by trigger configuration plus runtime-provided arguments. Depending on the trigger source, the automation may receive:
The trigger itself is defined only in the Automation Builder, using:
For the detailed reference of trigger resources, selector behavior, event groups, and trigger parameters, see Automation Triggers.
Automation variables help keep the action graph understandable. Use them when:
The automation stores its action graph as serialized content. At runtime, Jetstack rehydrates the action structure and resolves previous action links, trigger-aware parameters, and endpoint chains.
This matters because action sequencing and parameter scope are part of the automation contract, not just builder convenience.
Most automations are trees: the trigger fans out into a sequence of actions, endpoints branch into nested actions, and control flows top-down. Goto links and standalone actions extend that model for the cases where a strict tree gets in the way.
A goto link redirects control from one point in the graph to any other action on the canvas.
Where a link can start. Only outgoing slots that have no regular successor are eligible:
A small handle appears on hover over an eligible anchor. Dragging it onto another action creates the link. Filling a slot with a real successor (by dropping a palette item or moving a branch into it) removes any goto that was attached to that slot.
Runtime semantics: siblings only. When control reaches a goto link, it jumps to the target action and executes it, then runs the target's immediate scope-siblings in order. Once that scope is exhausted the automation ends. Control does not walk back up to resume the parent scope where the goto originated.
This rule keeps goto-based flows understandable: a link is a handoff, not a temporary detour. To run something and come back, use the existing "Run action" action instead — it remains the right tool for that case.
When to use goto links.
When not to use them.
A standalone (orphan) action lives on the canvas without a parent. The main run loop does not iterate standalone actions; they only execute when a goto link points at one. Once reached, a standalone action behaves like any other — it can have endpoints, nested actions, and its own outgoing goto links.
To create one, drag an action from the palette onto empty canvas space (not onto a drop zone). It appears with a dashed border and a "standalone" badge. Dragging it back into a regular drop zone converts it into a main or nested action, and any goto link that targeted it continues to work.
Use standalone actions to:
An order-processing automation validates an order, charges the card, and finishes with a receipt email. If the charge fails, the "error" endpoint of the charge action links to a standalone "Refund and notify customer" sequence. Control leaves the normal flow, the refund sequence runs, and the automation ends — no receipt is sent.
Each action exposes a set of input parameters configured in the action settings modal. A parameter has a name, an expected data type, and a value cell where you supply that value.
Two kinds of input controls are used:
When a parameter offers a specialized input, the action settings modal shows a small toggle next to the parameter's type. It switches that parameter between the specialized input and the default code editor. The choice is stored per parameter in the automation draft, so the same mode is used on every reload.
Use the default code editor when:
Use the specialized input when the parameter's value is one of the intended, well-known shapes. It is the faster, less error-prone choice for standard configurations.
Input values and the chosen input mode are stored with the action and participate in the normal draft/publish flow. Changing the input mode creates or updates the draft like any other edit.
Automations get a dedicated code processor with access to:
This is why automations can act as the main integration and workflow surface for many implementations.
The automation builder uses automation scope resolution to expose:
See Scope Resolvers.
Automations can be interrupted or redirected by exceptions and control-flow mechanisms such as:
Implementers do not need to memorize engine details, but they should understand that automations are closer to runtime workflows than simple "if this then that" rules.
A customer-onboarding automation might:
Customer object is created