How approvals work
Sooner or later something in Teralo will tell you it is awaiting approval, or land in My Items waiting for yours. This article explains what is actually happening, because the same machinery is behind every one of them and knowing it once saves working it out twenty times.
One engine, every tool
Permits, submittals, progress claims, variations, site diary entries, bookings, inductions, timesheets, method statements, observations, incidents, inspections, procurement and contract execution all route their approvals through the same workflow engine. Eighteen tool types run on it.
So an approval behaves identically wherever you meet it. The screen differs because the record differs; the reviewing, the responding, the reminders and the audit trail do not.
The shape of a workflow
A workflow is a diagram, built once and reused. It has blocks and the connections between them, and a record moving through it follows one path from the start block to an end block.
Most of the blocks are machinery you never see: setting a status, sending a notification, waiting for a date, branching on a condition. Only two kinds ask a person for anything.
A task is something to do. Somebody is asked to complete it, they do the thing, and they mark it complete. The record moves on.
A decision is a question with named answers. Approve or Reject is the common pair, but the answers are whatever the workflow's author wrote: Approve, Approve with comments, Reject. Some answers require a note before they can be given, which is how a workflow makes sure a rejection comes with a reason rather than leaving the next person guessing.
What happens when it reaches you
You are told twice. The item appears in My Items, and unless you have turned it off, an email arrives naming the record and saying what is wanted. If a step has a reminder set on it, a further nudge follows while it is still outstanding.
Open the record and the decision is on it, with its outcomes as buttons. Choose one, add a note if the outcome asks for one or if it would help, and the record moves. Nothing else is needed and there is nothing to submit separately.
Two things decide whether you can act. You have to be on the step, and you have to hold the permission the tool requires for that kind of action. Being on the step alone is not always enough, and for the tools where the stakes are highest it deliberately is not.
When more than one person is on a step
A step can be assigned to several people, and the workflow says how many have to respond.
Some steps wait for everybody. Every person on the step has to approve before the record moves, which is what you want when three parties genuinely all have to sign.
Others move on the first response. The step is assigned to a group so that whoever is free picks it up, and once one of them answers the record moves and it disappears from everybody else's list.
Either way, a rejection short-circuits: it routes immediately without waiting for the others, because there is no point collecting approvals for something already going back.
What rejection actually does
Rejected does not mean finished. Where a rejection goes is part of the workflow's design, and there are two common shapes.
Most often it loops back. The record returns to whoever submitted it, with the note explaining why, and they revise and resubmit; the workflow starts that stretch again. This is the normal case for claims, submittals and method statements, and it is why a rejection is a step in a conversation rather than a dead end.
Sometimes it ends. The record is closed as rejected and stays that way, which is the right design where resubmitting makes no sense.
Why an approval sometimes goes nowhere
An item that has not moved usually has a straightforward explanation.
It may be sitting with somebody else. The Upcoming in Your Queue section of My Items exists exactly to show a step that has not reached you yet.
It may be waiting on a condition rather than a person. Some workflows hold a record until something is true, such as no open defects against it, and the step's name says what it is waiting for.
Or it may have stopped. If a step fails and the workflow has no route for that failure, the run parks itself and emails the project's administrators rather than quietly doing nothing. That is a design choice: a stuck workflow that tells somebody is better than one that silently approves.
The trail
Every run keeps a record of itself: which blocks it went through, who responded, what outcome they chose, what note they left and when. The record's own history shows it, and it is the reason approvals go through Teralo at all rather than being agreed in an email thread nobody can find eighteen months later.
Setting them up
Everything above is what an approval looks like from the receiving end. Building one is the host's job, and it has a section of its own: start with What a workflow is, then The workflow builder for drawing one and Binding a workflow to a tool for putting it to work.