On this page
What an approval is
An approval is a review between “done” and “completed”. The assignee fills in the task as usual but only submits it for approval — a second authorised person completes it. Only with the approval does the task count as completed and the workflow advances to the next task. While the approval is pending, nothing downstream happens.
Setting up an approval on a task
The approval belongs to the template: you set it once on the task, and it then applies to every case created from that template. In the template editor, open the task in question.
- 1Open the template in the template editor and select the task that should be reviewed.
- 2Turn on the “Approval required (4-eyes)” switch.
- 3Under “Approver”, choose who may approve: “Any admin”, a specific role, a specific person, “Manager (of the submitter)” — the approval then routes automatically to the manager of whoever submits the task — or “External: …” for an external role, i.e. sign-off by the customer.
- 4With an external approver: in the task’s form, tick “Visible for external approval” on each field the customer should see. Everything else stays hidden.
- 5Publish the template — the approval applies from the next use onward.
The approver can be set as a role, a specific person, or the submitter's manager. A role is more robust against staff changes; a specific person is unambiguous when exactly one responsible reviewer should approve; “Manager” routes the approval up the reporting line (level selectable) to the submitter's manager — if none is set, it falls back to any admin.
A role as approver needs someone who holds it
If you pick a role as the approver, Bricksta looks among everyone who holds that role — either in THIS case (visible under “Participants”) or organisation-wide (Organisation › Roles › “Organisation-wide members”). Both count equally. So someone holding the role organisation-wide can approve even when nobody is staffed for it in the case itself.
Only when a role has no holders at all does the approval run into a dead end: submitting then shows “no approver other than you available”. The template editor warns you about this beforehand.
The easiest place to staff it is while creating the case: the create dialog and the start form on “My work” list the roles this template uses, and you pick the people for each role right there.
That selection is pre-filled from the “Preset for new cases” under Organisation › Roles. Enter there who usually holds the role — then it is already correct when you create a case and you just confirm it. The value is copied when the case is created; changing it later does not affect existing cases. If a case needs someone else, change the selection before creating it; if you pick nobody, the role stays unstaffed in that case. You can correct the staffing later in the case under “Participants”.
Cases that come into being without a dialog — through an automation, an intake form, a schedule or an AI agent — still get exactly the preset. There is nobody there to make a choice; for those routes the list under Organisation › Roles is the only source of the staffing.
If the approver role is unstaffed in a case, the task cannot be submitted — the message reads “no approver other than you is available”. The same applies when the role is staffed, but only with you: approval takes a second person. You do not find this out at submission time: the task carries the badge “Approval reaches nobody” in the case as soon as that applies to you — naming the role and the next step. Expand the task and the full advice sits as a hint band inside the task body — on a phone too, where a tooltip would be out of reach. Staff the role under “Manage participants” and the badge disappears right away; you do not have to reload the page. On top of that the template editor flags it at the approver and “Check template” reports it as a finding; those two speak about the template, the badge about this one case.
Approval by the customer (external role)
If the result should be signed off by the customer, pick an external role as the approver (“External: Customer”). The approval then goes to whoever is invited for that role in this case — they decide right in the customer portal, without a Bricksta account.
The role in the template is only the placeholder — who fills it is decided per case, and you do not need to prepare it. The task carries a single button, “For approval”. Click it while the role is still unfilled in this case and the confirmation asks for the email address — right where you also see what you are sending. One click on “Send for approval” invites the person and submits the task. The task’s ⋮ menu in the case view lets you withdraw the access while no approval is pending. Exactly one person fills the role per case: a second address is rejected, so that two people never end up allowed to decide unnoticed. If you mistyped, correct the address directly: “Change address” in the task’s ⋮ menu. The old access link dies immediately, and the new address has to satisfy the same four-eyes rule as the first — an address from your own organisation is rejected here too. The activity then shows one entry, “old → new”, instead of two separate ones.
The invited person receives exactly ONE email: the request for approval, linking straight to the decision. They hear nothing before that — while nothing has been submitted there would be nothing for them to do. Confirmation is only required to decide: the first time they open the portal link, they receive a six-digit code by email. An address belonging to a member of your organisation cannot be entered as an external approver — a sign-off you grant yourself would be none.
There they only ever see the task name and the fields you marked as “Visible for external approval” — read-only, without assignee, history or attachments. They can approve or send it back with a note; the note reaches the assignee and the task becomes editable again.
If you block the task while the approval sits with the customer, their decision is put on hold too: clicking “Approve” or “Request changes” in the portal is refused with a note that the approval is currently paused and that they will receive a new email once there is something to decide. They learn nothing about the reason for the block — that stays internal. Once you lift the block, they carry on deciding via the same link.
If nobody is invited or confirmed for that role, the approval falls back to any admin (and is logged). If the customer does not respond, admins can also decide themselves at any time (“Approve anyway”) — so a case never gets stuck. That override is recorded in the log.
If you withdraw a pending approval again (“Withdraw” on the task), the customer gets an email about it — otherwise they keep waiting for a sign-off that no longer exists. The reason you type into the dialog is sent along to the customer; the note above the input names the role that will receive it. If that person has not confirmed their portal access yet, they still get the message — but without your reason: a mistyped address must never deliver an internal note to a stranger. If nobody is reachable for that role, the message goes to the admins instead. If the customer still clicks the old mail link in the meantime, the portal tells them there is nothing to decide right now and that a new email will follow — the same applies once somebody else has decided.
The flow inside a case
- 1The assignee fills in the task and chooses “Submit” (instead of “Complete”).
- 2The task moves to “in review” and stays open — nothing downstream starts.
- 3From now on the form fields are locked — in both views. That is the point of an approval: the approver decides on exactly the result that was submitted. A note on the task explains why; if you do need to change something, withdraw the approval (see below).
- 4The “Responsible” column now shows a pair: on the left the person who submitted (rendered muted), on the right whoever the approval sits with. Who is up is visible at a glance.
- 5An approver sees a “Decide” button on the task. Clicking it expands the task — the filled-in fields and evidence become visible, and “Approve” and “Request changes” appear side by side at the bottom.
- 6On “Approve” the task completes and the workflow continues; on “Request changes” it goes back to the assignee with a reason.
Four-eyes means: whoever submitted a task for approval cannot approve it themselves. A different authorised person must approve or request changes.
Approve or request changes
- You decide right on the expanded task, not in a separate window: that way you see the content you are deciding about.
- Approve: a comment is optional. With the approval the task completes and the workflow proceeds.
- Request changes: a reason is required — the button stays disabled while the field is empty. The text is sent to the submitter; without it the task would come back with no explanation. The task returns to the “Changes requested” state so the assignee can rework it and submit again.
- Where the reason lands: the assignee sees it as a red band right above the form — in “My tasks” as well as in the case view, including who wrote it and when. A long text is clamped to six lines and opens fully via “more”. The task row itself carries only the “Changes requested” badge, so you can still spot the task in a list.
- A blocked task cannot be approved — lift the block first.
A task that has already completed is never reopened. A rejection does not reopen a completed task; it sends the still-open task back for rework — and the decision remains as traceable history.
Limits
Today there is single-stage approval: exactly one approver step per task. Multi-stage, parallel (several approvers at once) or conditional approvals are not yet available.