Understand the five core concepts
Learn how workflows, triggers, actions, connections, and runs fit together, then jump to the deep-dive for each one.
Five ideas explain almost everything you build in TaskJuice. A workflow is the automation you design. It starts with one trigger and flows through actions that do the work. The actions reach external apps through connections, the saved credentials you authorize once and reuse. Every time the trigger fires, TaskJuice records a run so you can watch what happened step by step.
Read this page once to see how the pieces relate, then follow the deep-dive for whichever concept you are working with.
The five concepts
A workflow is one trigger plus the nodes connected to it: a graph you edit on a canvas. You design it as a draft and publish it to a version. Only the active version receives live events, and publishing a new draft swaps the live version without interrupting runs already in flight. Read Workflows.
A trigger is the single entry point that starts a run. Actions and system nodes run downstream
to call apps, transform data, branch, or loop. Each step's output becomes addressable context,
so a later node can read an earlier one with expressions like $trigger and $steps. Read
Triggers and actions.
A connection is a credential you authorize once and reuse across workflows. Actions reference a connection instead of holding their own secret, so rotating or revoking access updates every workflow that uses it. Read Connections.
A run is one execution of a published version, pinned to the version it started on. It moves through statuses such as pending, running, waiting, completed, and failed, and you can replay a finished run or pause, resume, and cancel one in progress. Read The run model.
How they connect
A workflow holds the design. The trigger you pick decides what starts a run: an incoming webhook, a schedule, a new email, an RSS poll, or a manual start. When the trigger fires on the active version, TaskJuice opens a run and walks the graph node by node.
Each action does one unit of work, and many actions call an external app. That call needs credentials, which is where a connection comes in: the action references a connection you authorized earlier, so the secret never lives inside the workflow itself. As each step finishes, its output is recorded under its node ID, and downstream steps read it through expression aliases.
The run is your record of all of this. It captures the trigger payload, the status and timing of every step, and the input, output, and any error for each one. When something goes wrong, the run is where you read the failure and decide whether to replay it.
Batch triggers such as RSS, polling, and webhook collapse to one run per cycle or POST, not one run per item. A 50-item RSS poll produces a single run whose trigger payload is { items: [...] }. To process each item separately, add a Loop node inside the workflow. See the run model for how this shapes the run record.
Where to go next
If you are setting up your first automation, start with the quickstart and refer back here when a term is unfamiliar. If you are deciding how to structure a workflow, read workflows and triggers and actions together. If a run did not behave the way you expected, go straight to the run model.