Security & Data
Access Controls
The layers that decide who can view and edit what.
Access in Docpipe works in layers. Each one narrows what a person can reach, so sensitive knowledge stays with the people who should see it.
The three layers
- Organization — the outermost boundary. Everything you create belongs to your organization, and members of one organization can never see another's content. This separation is enforced on every request.
- Space — within your organization, each space grants members one of three levels: Viewer (read), Editor (read and change), or Admin (manage access too). A member can be limited to specific spaces, so they only ever see the areas they've been given. See Space access.
- Role — what a person can do at the organization level — managing members, integrations, and settings — is set by their role, separately from space access.
How they fit together
The two questions Docpipe asks are "which spaces can this person reach?" and "what may they do there?" Reading a document requires access to its space; editing it requires Editor or Admin access. Being an organization admin doesn't grant space access on its own, and authoring a document doesn't let someone who's since lost space access keep editing it — access always follows the space.
Under the hood
- Sign-in is handled by managed authentication, with Google sign-in and (if your workspace enables it) email and password. Sessions are kept in secure cookies, and anyone not signed in is redirected to log in.
- Organization isolation is enforced in two places at once: the application scopes every query to your organization, and the database itself applies row-level security policies keyed to your organization. A request only ever returns your organization's data.
Because access follows the space, the safest way to restrict something is to put it in a space only the right people can reach — not to rely on roles alone.