Approving and rejecting

This is the other side of a workflow: not building one, but being inside one. It is also the half most people only ever see, and it is the same wherever you meet it, because one engine runs every approval in Teralo.

How it reaches you

Three routes, all leading to the same place.

My Items is where everything waiting on you gathers, split by tool. For some things it is the only place: contract claim approvals live there and nowhere else, since the Contracts tool has no separate approvals page. The item shows the whole chain, so you can see who has already signed off and what happens after you.

The record itself carries the chip strip across the top, and you can act from there. Same decision, same outcomes, same audit entry. Which one you use is a matter of whether you arrived from your list or from the job.

Email carries the link. A well-written notification tells you what is being asked before you click, and the action itself always happens in Teralo, so the record and its trail stay in one place rather than being reconstructed out of mailboxes later. What reaches your inbox is yours to set. See Notification settings.

Making the decision

Open the record and the decision is on it, with its outcomes as buttons. The outcomes are whatever the template's author named: usually an approve and a reject, sometimes more where the process genuinely branches.

Choose one, add a note, and the record moves. Nothing else is needed and there is nothing to submit separately.

Some outcomes require a note before they can be given, and a good template puts that on rejection. Write it for somebody who was not in the conversation: what is wrong and what would fix it, rather than that it is not approved. That note is permanent and it is what the next person reads.

You can also attach a response: a marked-up drawing, a revised certificate, a photograph of the remediation. The attachment belongs to the approval step rather than floating loose in the document register, which is what keeps a decision and its evidence together.

What rejection actually does

Rejected does not mean finished, and where it goes was decided when the template was built.

Most often it loops back. The record returns to whoever submitted it with your note, they revise, and it comes round to the same review again. This is the normal shape for claims, submittals and method statements, and it is why rejecting something is cheap rather than final.

Sometimes it ends the run, closing the record as rejected. That is the right design where resubmitting makes no sense.

Either way a rejection routes immediately. It does not wait for other people on the same step, because there is nothing to be gained by collecting approvals for something already going back.

When you cannot act

An item that will not let you act usually has one of three explanations.

It has not reached you yet. The Upcoming in Your Queue section of My Items is exactly this: a step that will be yours once somebody ahead of you has acted. There is nothing wrong and nothing to do.

You are on the step but lack the permission. Being assigned and being permitted are two separate things, and on a few tools, notably timesheets and incidents, being assigned is deliberately not enough on its own. The fix is your permission template, not the workflow. See Assigning approvers.

Somebody else already answered. Where a step routes on the first response, whoever got there first has moved the record and it has left everybody else's list.

When nothing is happening

A record that has sat still for a while is worth checking rather than chasing.

It may be waiting on a condition rather than a person. Some steps hold a record until something about it is true, such as no open defects against it, and the step's name says what it is waiting for.

It may be waiting out a period deliberately, where the process gives a party a contractual number of days.

Or the run may have stopped. If a step fails and the template has no route for that failure, the run parks and Teralo emails the project's administrators rather than doing nothing quietly. The usual cause is a step assigned to somebody who has left.

As a guest

Guests approve exactly as described above. The builder and the bindings are host side, but being inside a workflow, and acting from the chips or from My Items, works identically. See Hosts and guests.

The trail

Every response is recorded: who acted, which outcome they chose, the note they left, the time. Hovering a chip on the record shows it, and it does not change afterwards, including if somebody later edits the template the run started under.

That permanence is the whole reason approvals run through Teralo rather than being agreed in an email thread nobody can find eighteen months later.