Building a workflow

The canvas

A workflow is built on a canvas. Add a step, then join it to the one before it. The connections are the order things happen in.

Adding steps

Add step opens the palette of what you can put in. Some steps can only appear once in a workflow, and the palette says so rather than letting you add a second.

Configuring a step

Select a step to set it up. What you configure depends on the step: which template a document uses, what question to ask, which condition to branch on, what formula to evaluate.

Steps are joined by values as well as by arrows. A later step can use what an earlier one produced by referring to it, which is what turns a sequence of steps into a workflow that actually carries information forward. See Passing values between steps.

Give steps names you will recognise

You will be referring to steps by name from other steps. Names that say what the step does make a workflow you can still read in six months, and make the references legible rather than a wall of ids.

What validation catches

Rhazes checks the workflow as you build it, and flags things such as:

• A step that is not reachable from the start.
• A reference to a step or a value that does not exist.
• A step missing something it cannot run without, such as a handoff with no target.

Fix these before putting a workflow into use. A workflow that fails halfway has already done some of its work, which is worse than one that never started.

Build it in the order it runs

Start at the input, add one step, and check it does what you expect before adding the next. A ten-step workflow assembled all at once and run for the first time is very hard to debug, because any of the ten could be the problem.

Changing one later

Workflows can be edited while they are in use. A run already in progress finishes on the version it started with, so editing does not disturb work already underway.

Re-test after editing, particularly if you renamed a step. Other steps may have been referring to it.