What a workflow is

A workflow is the route a record takes from submitted to settled: who reviews it, in what order, what happens when somebody rejects it, and what the record's status says at each point along the way. It is drawn once as a diagram and then reused, so the process is a thing you can look at rather than a thing people remember differently.

One engine runs all of them. That is the fact worth taking from this article, because it means an approval behaves the same wherever you meet it, and learning it once covers every tool that has one.

Blocks and paths

A workflow is blocks and the lines between them. A record moving through it takes exactly one path, from the trigger at the start to an End block.

Two kinds of block ask a person for something.

A decision puts the record in front of somebody and waits for an answer. Its outcomes are the buttons they see, usually an approve and a reject, and each outcome is its own path out of the block, so what happens next depends on which one they chose.

A task assigns work rather than a verdict: revise and resubmit, attach the certificate, book the inspection. The run waits until it is marked complete and then carries on.

Everything else is plumbing that runs without anybody touching it: setting a status, sending a notification, waiting for a date, branching on a value. See The workflow builder for all of them.

A run

A run is one record's journey through a template. The template is the shape; the run is what actually happened to this claim, this permit, this diary entry.

You can see it on the record. A strip of chips sits across the top, one per step, in order, coloured by state, so complete, current and upcoming steps look different at a glance. Hovering a chip says who acted and when. That strip is the audit trail, in the place you were already looking, and it is why nobody should have to ring round asking where something is up to.

Why rejection is not a dead end

Rejection is routing, not a special case. A reject outcome is a path like any other, and where it goes is part of the design.

The pattern worth copying drops the record into a lower lane: set the status to rejected, notify whoever submitted it, give them a task to revise, and loop back into the same review. That loop is what lets a rejected claim come back round without anybody starting again, and it is why a well-built workflow makes rejection cheap.

The other shape is a rejection that ends the run, which is right where resubmitting makes no sense. Both are legitimate; what matters is that somebody chose.

Where workflows apply

If a tool has a submitted state, it has a workflow behind it. Progress claims, variations, contract execution, procurement recommendations, submittals, site diaries, bookings, timesheets, incidents, observations, inductions, permits, method statements, inspections and more.

There is always a workflow, and some of them just say yes. Where a record type genuinely needs no review, the answer is not an empty setting but an auto-approve template: a trigger straight to an End block that approves. It sounds like ceremony and it is not, because it means every record has a recorded path rather than a silent gap, and a missing binding fails loudly instead of quietly approving. See Binding a workflow to a tool.

Reading on

The rest of this section follows the order you would build one in.

Templates and runs covers where a template lives and the difference between the organisation's standard and a project's copy of it. The workflow builder is the canvas and the full block palette. Assigning approvers is how to say who, and why naming a person is usually the wrong answer. Binding a workflow to a tool is the step people forget, because a template does nothing until something points at it. And Approving and rejecting is the other side: what it is like to be inside one.

If you are here because something is waiting on you rather than because you are building one, How approvals work is the shorter version.