Documentation
How organizations, roles and data boundaries work
What an organization owns, which role can do what, and why the scoping lives in the query rather than in the page.
Last reviewed against the product on .
Everything you import, cost and report on belongs to one organization. This page explains what that boundary is, because it is the thing standing between your supplier prices and everyone else's.
One organization, one set of data
Every purchase record, supplier, import run and report is stamped with an organization id, and every query filters on it. There is no view anywhere on this site that reads across organizations.
Roles
| Role | Can read | Can import and edit | Can administer |
|---|---|---|---|
| Viewer | Yes | No | No |
| Member | Yes | Yes | No |
| Owner or admin | Yes | Yes | Yes |
Measured from the role checks in src/lib/auth and the admin matrix in e2e/authorization.spec.ts.
A viewer who posts an import request directly to the API is refused with the same answer the interface gives them. Authorization is not a property of what the navigation shows.
The administration console
Separate from the workspace and restricted to owners and admins. A signed-out visitor is redirected to sign-in and never receives the console shell, not even an empty one, which matters because a rendered shell with no data still tells an attacker the page exists and what it is called.
What leaving looks like
Your data is exportable at any time from privacy. Export before you remove anyone's access, because removing access is the point at which their view of it ends.