Roles, permissions and row-level security
Every member has one role per workspace, owner, admin, editor or viewer. Roles are enforced by row-level security policies in the database, so the rules hold for the app, AI features and server functions alike.
The four roles
A person’s role is set per workspace. The same person can be an editor in one workspace and a viewer in another.
| Can they… | Viewer | Editor | Admin | Owner |
|---|---|---|---|---|
| Read SOPs in the workspace and libraries shared into it | Yes | Yes | Yes | Yes |
| Use Ask | Yes | Yes | Yes | Yes |
| Complete assignments, take quizzes, sign policies | Yes | Yes | Yes | Yes |
| Create and edit SOPs, cards and steps | No | Yes | Yes | Yes |
| Use Build with AI, imports, quiz drafting and the capture extension | No | Yes | Yes | Yes |
| Create and revoke share links | No | Yes | Yes | Yes |
| Move content between pillars by hand | No | Yes | Yes | Yes |
| Invite, remove and change the role of members | No | No | Yes | Yes |
| Permanently delete archived SOPs, and delete libraries | No | No | Yes | Yes |
| Run AI sort (Business plan) | No | No | Yes | Yes |
| Create and revoke API keys (Business plan) | No | No | Yes | Yes |
| Ask members to re-sign an updated policy | No | No | Yes | Yes |
| Grant the owner role | No | No | No | Yes |
Billing is managed by the owner of the workspace the plan was bought for.
How roles are enforced
SOPCompass enforces access in Postgres row-level security (RLS), not in the interface.
- The
memberstable is the single source of truth for who belongs to which workspace, with which role. - Every table in the app’s public schema has RLS turned on, with policies that check membership and role on each row.
- Small helper functions answer questions like “is the signed-in person an editor of this workspace?” They only ever answer about the person making the request.
- SOPs, cards and steps inherit who can see and edit them from their library.
- Operations that need extra checks, such as saving a quiz, signing a policy or moving an SOP, go through database functions that re-check the caller’s role themselves.
Because the rules live in the database, they apply equally to the app, to AI features (which run with your sign-in), and to anything else that reaches the database with your session.
Guard rails built into the database
- Last owner. A workspace can’t lose its last owner.
- Owner role. Only an owner can grant it.
- Lapsed billing. When a subscription is canceled or expired, editing and admin rights are paused, so the workspace is read only. Nothing is deleted.
- Private work stays private. AI interviews and capture drafts can be opened only by the person who created them, even by admins.
- Answers stay hidden. People taking a quiz can’t read the correct answers from the database.
- Append only records. Policy sign-offs can’t be edited or deleted by anyone signed in, and their time, version and signer are stamped by the database.
- Shared libraries are read only outside their home workspace.
How we test it
SOPCompass keeps probe scripts that sign in as a single workspace viewer and as an anonymous visitor, and check that neither can reach another workspace’s content, members or search results, or anything except a valid share link. The public API has its own suite of 90 checks, including isolation between workspaces, which last passed in full on 2026-09-19. This is our own testing, not an independent audit.
Common questions
Can an admin make someone an owner?
No. Only an owner can grant the owner role. The database refuses it from anyone else.
Can a workspace be left without an owner?
No. The database refuses any change that would remove a workspace's last owner.
What happens to editing when a subscription ends?
The workspace becomes read only. Editing and admin actions are refused until billing is back in order, and nothing is deleted.