The workflow builder
The builder is a full-screen canvas where a workflow is drawn as a diagram: blocks for the steps, lines for the paths between them. You read it left to right, and a process that fits on one screen is legible as a picture in a way a written procedure never manages.
Getting there
The builder opens from a tool's Workflows tab, at organisation level or project level, using Add Workflow for a new one or the edit action on an existing one. Because it is reached from the tool, the module is already decided, and the palette offers only blocks that make sense for it. See Templates and runs for where those tabs are.
Name the template before you do anything else. An unnamed template shows a validation error against the save button for as long as it stays unnamed, which is noise you do not want while you are working.
Starting a new one
A new workflow offers two ways in.
An empty canvas starts you with a trigger and an End block and nothing between them. This is the better way to learn, because you find out what each block does by needing one.
A description lets you write the process in plain English, the way you would explain it to a new starter, and turns it into a first draft on the canvas. Say who reviews, in what order, what happens on a rejection, and where a threshold changes the path. The more specific the description, the less editing afterwards.
A draft is a starting point rather than an answer, and it tends to be right about the shape and vague about the details. Two things are always worth checking on one: the assignment, since a draft cannot know your people and will have guessed, and the reject path, since the useful version loops back into review rather than simply ending the run.
Drafting from a description earns its place when you are converting an existing written procedure, or building the fifth variant of a process you already understand.
The blocks
The palette sits down the right-hand side. Drag a block onto the canvas or click to add it, and connect blocks by dragging between their handles. Clicking a block opens its settings in the same panel.
Trigger starts the workflow, usually on a record being submitted. Every template has exactly one.
Decision. Somebody reviews and picks an outcome, and each outcome routes its own path. Outcomes are yours to name: Approve and Reject is the common pair, but a decision can carry more where the process genuinely branches. An outcome can require a note before it can be chosen, and it is worth putting that on rejection every time: a rejection without a reason costs a phone call and a day, and a required note becomes part of the record rather than part of somebody's memory.
Task. Somebody does the work and marks it complete. Revise and resubmit, attach the certificate, book the inspection. Tasks are what make the reject lane useful rather than merely accurate.
If branches on a condition, true or false. Over a value threshold, take the longer approval chain.
Switch branches on a field value across several cases, which is the many-way version. Between them, If and Switch are how one template covers a whole module rather than needing one template per case.
Set status writes a state onto the record mid-run without ending anything: under review while it sits with the engineer, on hold while a certificate is chased. It is what keeps the register honest for the people reading it rather than acting on it. The statuses on offer are the module's own.
Notify sends through the module's own notifications, and carries an audience, a subject and a message. What you write is what lands in the recipient's inbox, so write it properly: a notification saying a record changed state is ignored within a week, and one saying what is needed and by when gets acted on.
Wait pauses the run for a duration, or until a date on the record. It is how you build a reminder that only fires if nothing has happened, and how you give a party their contractual number of days before the process moves on without them.
Wait for condition pauses until something about the record becomes true, checking periodically. A block waiting on one is named after what it is waiting for, so the chip on the record says something useful.
End terminates the run and sets the final state. A template can have several and usually should, because approved, rejected and withdrawn are different endings and the register ought to be able to tell them apart. A workflow with no End block is unfinished rather than untidy.
The reject lane
The pattern worth copying, and the one thing that most separates a workflow people follow from one they route around.
A reject outcome drops to a lower lane. Set status to rejected, notify the submitter with a message saying what to fix, give them a task to revise, then loop the task's completion back into the same decision it came from. The record goes round again rather than dying, and nobody starts a new one.
Working on the canvas
The toolbar along the bottom carries zoom, fit to window, auto-arrange, undo and redo, and a toggle between select and pan.
Auto-arrange is the fastest way to make a graph readable after you have been dragging blocks around, and it is worth running before saving so the next person opens something tidy. Fit to window afterwards rather than zooming back in: a graph laid out at full size is usually wider than the canvas has room for beside the palette.
Deselect before you leave. A selected block shows its settings panel, which is what you want while editing and not what you want as the first impression next time.
Saving
Create template saves a new one; an existing template saves in place. Until you save, the header carries an Unsaved changes chip, and leaving without saving discards the work.
Saving a template does not put it to work. A template does nothing at all until something points at it, and that is the step people forget. See Binding a workflow to a tool.