Understand the five core concepts
A short orientation to workflows, triggers, actions, connections, and runs, and how they fit together in TaskJuice.
Five ideas carry almost everything you build in TaskJuice. Once you can name them and see how they connect, the rest of the product reads as variations on the same shape. This page is the short map. Each concept has its own page with the depth.
The chain runs like this: a workflow holds an editable version of a graph. That graph starts with one trigger and flows into actions that use connections to reach outside services. Every time the trigger fires, you get a run.
Workflows
A workflow is the durable object you design and name. It owns a name, a description, a status, and a pointer to whichever version is currently live. It does not hold the canvas itself.
The actual graph, the trigger plus the connected nodes, lives on a version. A workflow can have many versions, but only one is Active at a time, and that active version is the one receiving live events. Versions are numbered (version 1, version 2, and so on), so you always know which snapshot of your design is running.
This split is what lets you edit a live workflow without taking it down. When you change the graph of an active version, TaskJuice does not overwrite the running version. It creates a new draft labelled "Draft from v2" and leaves the active version dispatching as before. The active version keeps running until you publish the draft, and the moment you publish is the moment the live version swaps. Runs already in progress finish on the version they started on, because each run is pinned to its own version.
A workflow moves through five statuses: Draft, Published, Archived, Disabled, and Paused (safety). The first two cover the normal path. A workflow flips to Published automatically when one of its versions becomes active, and drops back to Draft when its last active version is deactivated. Paused (safety) is a protective stop the platform applies when it detects a misconfiguration; you clear it by fixing the config and resuming from the workflow page.
The workflow status (Draft, Published, Archived, Disabled, Paused (safety)) describes the container. The version status (Draft, Compiling, Active, Inactive, and a few validation states before a version goes live) describes one snapshot of the graph. They move together but are not the same set. See Versioning for the full version lifecycle.
Triggers and actions
Every workflow graph has exactly one trigger: the single entry point. The trigger decides what starts a run. It might be an incoming webhook, a schedule, a polling check, an RSS feed, an email, a form submission, or a manual start. There is one trigger per workflow, never two.
Everything downstream of the trigger is a node that does work or controls flow. These come in two kinds:
- App actions are operations on a connected service, such as sending a Slack message or creating a HubSpot contact. They come from the integrations catalog.
- System nodes are built-in platform nodes that are not tied to any one app, such as Branch, Switch, Loop, Parallel, Transform, HTTP, Code, Delay, and the AI nodes.
The piece that makes a multi-step workflow useful is how data flows between steps. Each step's output is captured in an immutable snapshot, so a later step can read what an earlier step produced. You reference that data with expression aliases: $trigger for the trigger's payload, $steps for the output of any prior node, $input for the current node's input, and $meta for engine metadata like routing decisions. For example, $trigger.email reads the email field from the event that started the run, and $steps.<nodeId>.data.<field> reads a field from a specific upstream step.
Webhook, RSS, and polling triggers collapse a batch into a single run. A 50-item RSS poll fires one run whose payload is { items: [...] }, not 50 separate runs. To process each item, add a Loop node downstream and point it at the items array. Reference the first item directly as $trigger.items[0].<field>.
Connections
A connection is a reusable, stored credential for an outside service: an OAuth grant, an API key, or an account subdomain. You connect an account once, then any action that talks to that service reuses the same connection. You do not re-enter credentials per workflow.
Connections are scoped. An account-scoped connection is available across your workspaces; a workspace-scoped connection stays inside one workspace. This scoping is how an agency keeps one client's credentials isolated from another's. Connecting an account is the same flow for every app, whether it uses OAuth, an API key, or a subdomain.
Runs
A run is one execution of a published workflow version, started when the trigger fires or when you start it manually. Each run is pinned to the workflow version it began on and tracks per-step progress as it goes.
A run carries one of seven statuses:
| Status | What it means |
|---|---|
| Pending | Queued, no steps have started yet |
| Running | Actively executing steps |
| Waiting | Parked on a delay, an approval, a form submission, an event, or a pending client connection request |
| Paused | Stopped by an operator or by a safety control |
| Completed | Finished successfully |
| Failed | Stopped on an error |
| Cancelled | Stopped by a cancel action |
Completed, Failed, and Cancelled are terminal: a run in one of those states is done and will not change on its own. Inside a run, each step has its own status. Steps use the same set plus Skipped, which marks a step on a branch that did not run. The success word is always Completed, at every level.
When something goes wrong, you have two recovery paths. Run control lets you pause, resume, or cancel a run that is still in flight. Replay creates a brand new run from a previous one: you can re-run it as-is, or re-run it with a new prompt or a new model, which is useful for fixing a bad input without rebuilding the workflow. Replay does not re-execute the old run in place; it returns a new run ID. Replays are limited to 20 per minute per workspace, and a replay of a run still in flight is rejected.
How they fit together
Read this top to bottom and you have the whole model:
- You design a workflow and edit its current version.
- The version's graph starts with one trigger and flows into actions and system nodes.
- Actions reach outside services through connections.
- You publish the version to make it Active, which is when it starts receiving live events.
- Each firing produces a run you can watch, control, and replay.
That is the whole map. When you want the depth on any one primitive, the Core concepts hub routes you to a dedicated page for each.
Next steps
- Read the deep dives, starting with Workflows and The run model.
- Build your first one in the Quickstart.