Roles and permissions

Who may edit, approve and publish a controlled document is decided by the role you hold, and every one of those decisions is made on the server rather than in the browser. This page is the full rule.

Two kinds of role

Alchex uses two independent sets of roles, and it helps to keep them apart.

Workspace roles — Owner, Admin, Member — decide who runs the workspace: inviting people, changing workspace settings, billing, creating and deleting teams. You pick a workspace role when you invite someone.

Team roles — Reader, Writer, Owner — decide what someone can do to the controlled documents belonging to that team. You pick a team role when you add a person to a team, and you can give the same person different roles on different teams.

One shortcut connects them: a workspace Admin or workspace Owner counts as a team Owner on every team, without being added to it. Everyone else has exactly the team role you gave them — and someone who is on no team at all cannot see that team's documents, even to read.

What each role can do

The table below is the live rule, not a summary of it. Every row is enforced on the server, so a role can never do something through a shortcut, a link, or a stale browser tab that it could not do through the normal screens.

* Subject to the separation-of-duties rule below.

A few things worth spelling out:

• Reader really is read-only. A Reader cannot create, edit, comment, submit or archive anything. There is no "just this once" exception.
• Commenting is a Writer action. Leaving review feedback counts as contributing to the document, so it sits on the same rung as editing.
• Removing a document is archiving it, and that is a Writer action. It takes the document out of circulation but does not destroy it: every version, approval and stored file is kept, and Restore on the archived document's banner brings it back. Removal sits on the same rung as proposing a change, which is what makes it safe: it is reversible. Permanent delete is a separate, Owner-only door on the Governance list, and it refuses a document that ever published — its versions and approvals are a record somebody may hold — so what it is for is the draft that never became one. A control's definition document is not an exception any more: archiving it archives the control with it (a Writer action, the same rung), permanently deleting it removes the control, its wiring and the definition together (an Owner action, the same rung), and moving it takes the pair to the new team. If the control carries an audit verdict you are asked before it is cleared — see Activity and archive.
• Nothing about removal depends on what cites the document. A record other documents point at can still be removed by anyone whose role reaches it; the citing chips pick up a red dot and can be re-pointed. Removal is never refused on that account, so there is no admin-only way around a refusal either. That holds for the permanent door too, and for every kind of record — deleting a cited register is not refused either. See References and Activity and archive.
• The two rungs are the same for every kind of record. Archiving and restoring a document, a register or a risk record is a Writer action; permanently deleting any of them is an Owner action. There is one rule to learn, not one per kind. (Risk records joined on 2026-09-09: until then a risk had only a soft delete, with no way back and no permanent door.)
• Publishing and approving are the two Owner-only powers — the moments where content becomes official.

Editing is governed by your role and by the document's state — archived documents are read-only for everyone. A pending review does not lock the record: the approver decides on the copy pinned at submit, so editing carries on and rides the next round. See Drafts and Submit and approve.

A review belongs to the person it names

The rule that decides who approves what:

A review is submitted to one person, and only that person can decide it.

Two things have to be true, and no role lifts either. The approver must hold Owner on the record's team (or be a workspace Owner or Admin, who count as Owner everywhere) — and they must be the person the review was sent to. Another Owner of the same team opening that review has no approve button and is refused by the server if the request arrives anyway: "This review was sent to someone else to decide."

The check does not rely on anything your browser sends. When a decision arrives, Alchex reads who the review names from the approval record itself and compares it with your signed-in identity. That is why it survives page refreshes, shared links, and copied requests.

Approving your own submission is allowed. Name yourself when you submit and the review is yours to decide. Alchex records who asked and who decided on every review, so the trail distinguishes a self-approval from a colleague's decision — it just does not forbid the first one. Until September 2026 it did, which meant a workspace with one Owner could file a review nobody could ever finish.

Two clarifications that come up often:

• Who you can name is bounded by the rung, because naming hands over the decision. You can only send a review to someone who could have published the record anyway. Otherwise a Writer could send a draft to themselves, approve it, and publish without ever holding the right to publish. The request form lists exactly the people you may choose from.
• Publishing directly skips review entirely — and it is a server verb, not a button. The publish verb, at the Owner rung, can issue the current draft without opening a review at all; the app itself offers no way to press it. It is recorded explicitly as a direct publish, so it is always visible in the history, and it is refused while any review is pending, so it cannot be used to jump one. See Publishing.

If your organisation needs a second pair of eyes, that is a choice you make when you submit — name a colleague rather than yourself. Alchex no longer enforces it for you, because enforcing it made the product unusable for the workspaces that have one accountable person.

Choosing roles in practice

A workable default for most teams:

• Reader for people who need to follow the rules but never write them.
• Writer for the people who draft and maintain documents, and for anyone whose feedback you want in comment threads.
• Owner for the small group accountable for what the team publishes. A second Owner is worth having if you want submissions reviewed by somebody other than their author — that is now a habit you keep rather than a rule Alchex enforces, so with one Owner reviews still work, they are just self-approved.

Reserve workspace Admin for people who genuinely administer the workspace, and remember it silently grants team Owner everywhere.

Where to change roles

Workspace roles and invitations live in workspace settings, under Members. Inviting someone sets their workspace role, their starting team, and their role on that team in one step; the invitation link expires after seven days and works once.

Team roles live on the team itself, under Members. Only a team Owner (or a workspace Admin/Owner) can add people or change their role there, and you cannot remove your own Owner access from that screen.

Changes take effect immediately. If you are new to the workspace model, start with the Overview; to see how these roles play out across a document's life, read Submit and approve and Comments.