Skip to main content
A workflow turns one incoming event into a graph of actions. Its trigger decides when a run begins, its actions decide what happens, and its connections decide which values and dependencies move through the graph. Unlike a checklist, a workflow does not run from top to bottom. Position on the canvas is only for readability. The connections between nodes determine execution order.

​
Anatomy of a workflow

Every workflow has one trigger. You choose it when creating the workflow, then configure it from the trigger button in the editor header. If you need a different kind of trigger, create another workflow and move or recreate the relevant actions there.

​
Build on the canvas

1

Start with the trigger

Create a workflow from the project’s Workflows page and choose the event that should start it. The new graph includes Data from Trigger, displayed with the selected trigger’s name and outputs.
2

Add actions

Press /, ⌘ K, or ⌘ P to open action search. Select an action to add it near the center of the canvas.
3

Configure values

Select an action to open its configuration panel. Enter fixed values there, or connect values from other nodes to its inputs.
4

Connect dependencies

Drag from an output handle to an input handle. A connected action waits for that upstream value before it can run.
5

Wait for the save

Graph changes save automatically. Check the header for Saved before sending a test event, closing the page, or relying on the new version.
See Actions for node configuration and Triggers for choosing and configuring the event source.

​
How the graph runs

When a trigger creates a run, WorkflowDog starts every action whose dependencies are ready. This has several consequences:
  • Actions on independent branches can run at the same time.
  • An action with two connected inputs waits for both upstream values.
  • A fixed value does not add an upstream dependency.
  • Moving a node left, right, above, or below another node does not change execution order.
  • A circular set of dependencies is invalid and cannot be saved.
For example, if Fetch Customer and Fetch Orders both depend only on trigger data, they can run concurrently. An action connected to both waits until both branches resolve.
If one action must wait for another without consuming its value, add the Wait For meta control. Conditions and error-handling outputs are covered in Meta controls.

​
What happens when a branch stops

Connections carry execution signals as well as values. If an upstream action is disabled, skipped by a condition, or fails, its normal outputs do not produce values. Actions that require those outputs do not run. Other branches that do not depend on the stopped action can still finish. This is why a run can complete with one or more action errors rather than failing as one indivisible transaction. Use the action’s Did Action Succeed?, Error, and related meta outputs when another branch should react to that outcome. See Meta controls for the complete pattern.

​
Edit safely

WorkflowDog keeps a short local undo history while you edit:
  • ⌘ Z undoes the latest graph change.
  • ⌘ Y or ⌘ ⇧ Z redoes it.
  • Selecting multiple nodes exposes alignment, layout, enable/disable, duplicate, and deletion tools.
  • Automatic layout is available from the editor toolbar.
Each run keeps a snapshot of the workflow graph it started with. Editing the workflow affects future runs, not the historical graph attached to an existing run. Learn how those snapshots appear in Workflow runs.

​
Next steps

Once the graph is ready, test it with a real trigger event. Then use Enable and pause to control whether it accepts new events.