Workspace isolation

One database, separated by row-level security

SOPCompass is a multi tenant application. Every workspace lives in the same Postgres database, and each row carries the workspace it belongs to. Row-level security policies on every table only return rows from workspaces the signed-in person is a member of.

This means:

• Searching, asking a question or opening a link with another workspace’s id returns nothing.
• A forged workspace id in a request doesn’t widen access, because the database checks membership, not the id the browser sent.
• AI features read content with the requesting person’s own sign-in, so they are bound by the same rules.
• API keys see only their own workspace, plus libraries shared into it.

Moving content can’t cross workspaces

Database triggers refuse any change that would move a library or SOP into a different workspace, whoever makes it, including our own server processes. Content leaves a workspace only by being shared or exported by someone with access.

Library sharing, on purpose

On the Business plan, an editor can share a library from its home workspace into other workspaces they also belong to. Inside those workspaces:

• the library is read only,
• it can be edited only from its home workspace, and
• assignments, quiz attempts and sign-offs made there belong to the workspace that made them.

Before a move takes an SOP away from a workspace that can currently see it, the app shows which workspaces lose it and asks for confirmation.

What is private even inside a workspace

• AI interviews and their proposals: only the person who started them.
• Capture drafts: only the person who recorded them, until published.
• Ask history: only the person who asked.

What members of a workspace can see

Members can see the workspace’s SOPs, its member list, its activity feed and its Ask question log (the text of questions, without who asked). Keep that in mind when you decide who to invite, and as which role.