Workflows

A workflow is the template a process runs under. It is a graph: each node is a stage, each edge is a dependency between stages.

Templates and jobs

The distinction matters more than anything else on this page.

A workflow is the design. A job is one piece of real work moving through it, and it takes its own copy of the graph when it is created. The copy is what makes versioning safe: editing a workflow cannot reach into a job that is already running.

Every job records the version it started from. When you fetch one, dagVersion is the version it was created under and currentDagVersion is where the template is now. When they differ, the workflow has been published again since the job began, and the job is unaffected.

Creating one

In the editor

1. Go to the workflows page.
2. Create a new workflow.
3. Add stages and connect them on the canvas.
4. Configure each stage.
5. Publish.

Over the API

Creating a workflow gives you an empty template with a start and an end stage. Stages are added afterwards, one call each.

curl -X POST https://takiflo.runasp.net/api/dag \n  -H "Authorization: Bearer $TAKIFLO_JWT" \n  -H "Content-Type: application/json" \n  -d '{
  "name": "Customer Onboarding",
  "maxRepeats": 0
}'

Stage types

How a join decides

A join opens based on the states of the branches feeding into it, using one of three operators.

And is the common case: two approvals running in parallel, and the next stage waits for both. Or is what you want when either of two reviewers can sign off.

Loops

A loop node sends work back to an earlier stage and clears the stages between them, so the rework is genuinely redone rather than left marked complete. maxIterations caps how many times that can happen; leaving it unset means uncapped.

This is what a rejected document looks like in a real process: back to the collection stage, with everything after it reset.