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.
• Archiving is a Writer action too — it takes a document out of circulation but does not destroy it, and it stays visible in the archive.
• Publishing and approving are the two Owner-only powers — the moments where content becomes official.

Editing is also limited by the state of the draft, not just by your role. While a draft is sealed for review, even an Owner will be refused a content edit until the review is decided. See Drafts and Submit and approve.

Separation of duties

The single most important rule in the whole permission model:

Whoever submitted a document for review cannot approve that same review — not even a workspace Owner.

There is no role that lifts this. If you submitted the draft, the approve and send-back buttons are unavailable to you on that review, and the request is refused by the server if it arrives anyway. Someone else with Owner rights on that team has to make the call.

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

Two clarifications that come up often:

• The rule keys on the submitter, not on who typed the words. An Owner who helped edit a draft that someone else submitted may still approve it. If you need contribution-level separation, use the activity trail to show who touched what.
• Publishing directly is the one sanctioned self-approval. A team Owner may publish the current draft without a second pair of eyes — it is recorded explicitly as a direct publish, so it is always visible in the history. It is refused while somebody else's review is still pending, so it cannot be used to jump a queue. See Publishing.

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. Keep it to at least two people — with only one Owner, that person's own submissions can never be approved by anyone else, and separation of duties collapses into direct publishing.

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.