# Building workflows

> The rules a workflow graph must follow, the order branches run in, how drafts keep unfinished work, and what happens when automations trigger each other.

Source: https://joely.io/documentation/automations/building-workflows
Last updated: 2026-09-25

## Structure rules

A workflow flows outward from **at least one trigger** (none of which may have an incoming connection) and must contain **no cycle** and **no disconnected node**.

Several triggers are allowed, so one chain can answer several events — see [Several triggers in one workflow](https://joely.io/documentation/automations/triggers.md#several-triggers-in-one-workflow) for what a node shared by two of them can read.

Each output — a condition's *True* and *False*, a chat message's choices, the single output of every other node — can feed **any number of connections**. Only an exact duplicate (the same output connected twice to the same node) is refused.

The one ordering rule: nothing can point back into a trigger. Conditions and actions can otherwise connect in any order, including an action followed by a condition that tests what it produced.

## Branch order

When an output fans out to several branches, the branches run **one after the other**, from **top to bottom as their nodes are laid out on the canvas** (at equal height, left to right). Move a branch's first node above its sibling to run that branch first.

- A branch finishes **completely** before the next one starts.
- Everything a branch produced is available to the branches that run after it.
- Two branches may **re-converge** on a shared downstream node. It then runs **once per branch** that reaches it.

> **Example** — a condition's *True* output feeds both **Assign to a user** and a **Discord notification** sent to the *assigned team members*. Recipients are resolved when the node runs, so placing the assignment above the notification is what makes the newly assigned member receive it.

## Drafts

Your work is never lost to a validation error. When you save a workflow that isn't complete — no trigger yet, a node left unconfigured, no action, or any other structural problem — it is saved as a **draft** rather than rejected.

A draft keeps everything you built exactly as it is, shows a **Draft** badge in the list, and **never runs**. The editor lists what's left to finish so you know how to publish it.

**Enabling** a workflow (turning it on) requires a fully valid graph, and that check runs both in the editor and on the server: a draft cannot be enabled until it's complete. If you edit an **enabled** workflow in a way that makes it invalid, it drops back to a draft (and stops running) instead of staying live but broken — so a workflow that is on is always one that actually works.

**Saving turns a workflow on by default.** A new workflow is created enabled as soon as it is complete, and a draft is published by the save that completes it — including a workflow that dropped back to a draft after an edit. The one exception is a workflow you turned off yourself: it stays off when you save it, until you turn it back on. A workflow locked by your plan's workflow limit is saved turned off.

## Automations can trigger each other

An action can set off other workflows: a message a workflow posts, or a status it changes, is an event just like any other, so a workflow that reacts to it will run. This lets you compose behavior across workflows — for example, *On status changed → Post message*, then *On chat message → …* reacting to that message.

To keep a chain from running forever, everything set off by one original event runs as a single **chain**, watched by three safeguards:

| Safeguard | Limit |
|-----------|-------|
| Identical step repeated in a chain | Stopped the second time |
| Actions in one chain | 100 |
| Node steps in a single run | 200 |

- A workflow runs **at most once per identical step in a chain**. A step is the same when the *same workflow* reacts to the *same kind of event with the same meaningful data* and performs the *same actions*. If a chain would repeat that exact step (the classic A → B → A loop), it is stopped instead. A workflow reacting to genuinely **different** data — for example the ticket moving to a *different* status later in the chain — is a legitimate new step and still runs.
- A chain can run **at most 100 actions** in total. This also bounds a chain whose data keeps changing every step (which the repeat check cannot catch): it is stopped when it reaches the limit.
- A single run can execute **at most 200 node steps**. Branching out and re-converging multiplies the paths through a workflow, so one run's total work is capped too.

A stopped step is recorded in the run history as **Loop stopped**, with the reason, so you can spot and fix a workflow that loops. Nothing is lost: the steps that ran before the safeguard tripped still took effect.

One case still does not start a chain: a [closure requested from the portal](https://joely.io/documentation/automations/triggers.md#status-changed) never triggers workflows, so nothing an automation does can be set off by it.