Assigning approvers

Every decision and every task in a workflow has to say who it is for. There are three ways to answer that, and which one you pick decides whether the workflow still works in a year.

Three ways to say who

A named person. The obvious answer and the most brittle. It is right where the role genuinely is one individual and the process would be wrong without them, and wrong nearly everywhere else, because it breaks when they are on leave and breaks permanently when they leave the company. A named assignment is fixed at the moment the run starts.

Everyone holding a permission. The step goes to whoever holds a given permission on the project at the moment the step is reached. This is usually the right answer: it survives staff changes, it covers leave without anybody editing a template, and it says what you actually mean, which is that the commercial manager approves rather than that Sarah approves. See How permissions work.

Whoever a field on the record points at. The step follows the data: the subcontractor's own representative reviews their own submission, the person a defect is assigned to closes it out, the inspector named on the plan does the inspection. This one is resolved when the step is reached rather than when the run starts, so if the record is reassigned partway through, the reassignment is respected and the loop picks up the new person.

Prefer the last two. The rule of thumb is that a template should read as a description of your process, and a name in it usually means the process was not written down properly.

More than one person on a step

Assigning by permission or by field often resolves to several people, and the template says how many of them have to respond.

Everybody waits for every person on the step to approve before the record moves. This is what you want when three parties genuinely all have to sign, and it is worth using sparingly, because one person on leave stops the job.

The first response moves the record as soon as any one of them answers, and it disappears from everybody else's list. The step is assigned to a group so that whoever is free picks it up, which is what you want for a review that any of four people could do.

A rejection short-circuits either way. It routes immediately without waiting for the rest, because there is no point collecting approvals for something that is already going back.

Reminders

A decision or a task can carry a reminder, which nudges whoever it is waiting on while it is still outstanding.

Set them where a delay costs something and leave them off where it does not. A reminder on every step teaches people to ignore reminders, which is worse than having none.

Being on the step is not always enough

Two things decide whether somebody can act: they have to be on the step, and they have to hold the permission the tool requires for that kind of action.

Most tools let somebody who manages the tool act whether or not they were assigned, which is the sensible default for a site diary or a booking. A few deliberately do not. On timesheets and incidents, someone holding the manage permission but not assigned to the step cannot approve, and only a project or host organisation administrator overrides that. Those are the two places where quietly widening who can approve would matter most, which is exactly why they are stricter.

Inspections go the other way and check only the permission, matching how the tool has always worked.

The practical consequence: if somebody says they cannot act on a step they are clearly on, the answer is nearly always their permission template rather than the workflow.

Guests as approvers

Guests are assigned to steps routinely and act on them exactly as hosts do, from the record or from My Items. What stays host side is the builder and the bindings, not participation. See Hosts and guests.

Where a step should reach the submitting organisation rather than yours, assigning from a field on the record is what does it, because the record already knows whose submission it is.

When a step cannot find anybody

If an assignment resolves to nobody, the run does not quietly skip the step. It stops, and Teralo emails the project's administrators saying so.

That is a deliberate choice: a workflow that halts and tells somebody is better than one that silently approves. The usual causes are a named person who has left, or a permission nobody on this project holds, and both are worth checking on any template you have copied from another job.