Tenant isolation
Oblifee is multi-tenant: many workspaces run on the same platform. This page explains how your workspace's data is kept separate from every other workspace's - not by careful coding alone, but by the database itself.
:::info The short version Every row of your data carries the identity of the workspace it belongs to, and the database is configured to refuse any query that would return a row belonging to a different workspace. The separation is enforced below the application, so a bug in application code cannot leak one workspace's data to another. :::
Workspaces, and what lives in one
A workspace (also called a tenant) is your isolated environment. Everything you create - businesses, brands, products, packaging, volumes, registrations, imports, label checks and reports - belongs to exactly one workspace and is tagged with its identity. Your user account can belong to more than one workspace (for example, a consultant looking after several clients), but each workspace's data stays in its own boundary.
Row-level security
The separation is done with row-level security (RLS), a PostgreSQL feature that attaches a rule to a table. Every request, when it resolves which workspace it is operating on, sets that workspace's identity on the database connection. From then on, the database transparently adds "...and only rows belonging to this workspace" to every read and every write. There is no way to ask for another workspace's rows: the policy filters them out before your query ever sees them, and it blocks any attempt to write a row into a workspace that is not the active one.
Two properties make this robust:
- It is enforced, not requested. The application role Oblifee uses to reach the database is not permitted to bypass row-level security. Even if a query forgot to filter by workspace, the database would still apply the policy.
- The database decides, not the code path. Isolation does not depend on every screen, report or background task remembering to add the right filter. The rule lives in one place - the database - and applies everywhere at once.
Within a workspace: business-level access
Isolation does not stop at the workspace boundary. Inside a workspace you can grant a team member access to only certain businesses. That grant is enforced the same way: the request carries the set of businesses the user is allowed to touch, and the database's policy narrows their view to those businesses. Picking a single business in the switcher can only ever narrow what a user sees, never widen it. Owners and admins are unrestricted within their own workspace.
| Boundary | Who it separates | Where it is enforced |
|---|---|---|
| Workspace | Your data from every other workspace | Database row-level security |
| Business | A member's businesses from the rest of the workspace | Database row-level security |
The regulatory brain is shared, and read-only
One dataset is deliberately not per-workspace: the regulatory brain, the cited set of rules, fees and thresholds. It is the same reference data for everyone and Oblifee can only ever read it. Your workspace's data is never written into it. See Regulatory brain integrity for how that separation is maintained.
What this means for you
- Your products, packaging and volumes are visible only inside your workspace.
- Team members you invite see only what their role - and any business-level grants - allow.
- There is no shared table where one customer's figures could appear in another's results.
Where to go next
- Authentication - how users prove who they are before any of this applies.
- Data handling - what data is stored and for how long.
- Security & trust overview - the whole picture in one place.
- Team & roles - granting and revoking access within a workspace.