Chaining workflows together
Finish one Rhazes workflow by running another, chaining several small workflows into a pipeline that runs unattended on a schedule.
Updated
What a handoff does
A workflow can finish by handing off to another one. The second workflow genuinely runs, taking over from where the first finished.
This is how several workflows become a pipeline. Rather than one enormous workflow that does everything, you build small ones that each do a job properly, and chain them.
What you can hand off to
Your own workflows, and Rhazes' built-in capabilities. Anything you have built is available as a target.
A workflow cannot hand off to itself. It is excluded from its own list of targets, so a chain cannot accidentally loop back on itself.
Why build it this way
Small workflows are easier to get right, easier to test, and reusable.
An intake workflow that ends by handing off to your documentation workflow means the documentation workflow is one thing, maintained once, used by everything that needs it. Change how your letters are written and every chain that ends in it changes too, rather than you editing the same steps in five places.
It also makes failure easier to read. When a chain stops, you can see which workflow it stopped in, instead of hunting through forty steps of one large graph.
It runs on schedules too
A handoff is not limited to workflows you run by hand. A scheduled run hands off exactly the same way, and the target does the real work rather than the run stopping and telling you to go and do it in a chat.
That is what makes an unattended pipeline possible: the overnight run can prepare, then hand off to the workflow that produces the output.
Give it a target
A handoff step with no target set cannot run, and Rhazes flags it while you are building rather than letting it fail on a patient. If a chain is not firing, an unset target is the first thing to check.
Retries do not run it twice
If a run is retried, a handoff that already completed is not run again. A chain cannot quietly bill twice or produce two copies of the same document because something further along was retried.
Designing a chain
- Split on the natural seam, usually where the output of one job becomes the input of the next: gather, then document, then file.
- Keep each workflow independently useful, so you can run the documentation half on its own when you only need that.
- Test each link by itself before chaining them, since a chain is only as reliable as its least tested step.
- Watch the whole chain end to end once before scheduling it. See Following a Rhazes workflow run.