Each of your customers runs inside an organization in your workspace. Organizations share your workspace's infrastructure — one database, one dashboard, one mobile app — but their data is kept separate by access rules enforced in the database itself. This page explains where that boundary sits and what crosses it.
Isolation is enforced in the database
Every form and record row in the database is tagged with the organization it belongs to. Access is controlled by row-level security policies — rules attached to the tables themselves that filter every query by the requesting user's organization context. The policies check two things: which organization the user is currently acting in (carried in their signed session token) and whether a membership row actually connects that user to that organization.
There is one deliberate exception, and it is worth stating plainly: an instance owner — you and your team, the people running the workspace — can enter any organization without a membership row, and sees its data once they do. Entering an organization the owner does not belong to is written to the audit log. Your customers' staff have no such bypass: for them, membership is required and the boundary is absolute.
Because the check lives in the database rather than in application code, dashboard queries and mobile sync cannot skip it — a bug in a screen cannot leak another organization's rows, because the database never returns them. The customer API takes a different path: each API key is bound to its organization, and that binding is checked on every request — plus again inside the database functions that perform the work — before any query runs.
Every request carries organization context
Users can belong to more than one organization, so "who is asking" is not enough — every request also establishes which organization the user is acting in. The dashboard and mobile app set this context at sign-in and when the user switches organizations; the session token then carries it on every query. A user who is a member of organizations A and B, currently working in A, sees only A's forms and records — B's data stays invisible until they explicitly switch.
API keys follow the same model: an organization-scoped key can only address its own organization's paths, enforced by the key's binding. See authentication for details.
What is shared, what is isolated
Shared across all organizations in your workspace:
- Workspace branding and settings — the app name, logo, and colors your customers see. Managed in instance settings.
- The platform itself — one dashboard, one mobile app build, one API surface.
Isolated per organization:
- Records — submissions never cross organization lines.
- Members and roles — each organization has its own member list, and a user's role in one organization grants nothing in another.
- Data sources — lookup tables that feed form dropdowns belong to one organization.
- Webhooks and organization-scoped API keys.
Logical isolation, honestly stated
Organizations are logically isolated within one shared database, not physically separated into different servers. This is the same architecture used by most multi-tenant business software, and the row-level policies that enforce it are tested directly — including tests that attempt cross-organization access and verify it fails. We state this plainly because IT reviewers ask: the boundary is real and database-enforced, and it is logical rather than physical.
The other question IT reviewers ask is who can cross it. The answer is the workspace operator and no one else: an instance owner can enter any organization, and every such entry is recorded in the audit log. Between organizations there is no path at all — no role, no API key, and no shared view lets one organization's users reach another's data.
For how organizations are created and managed day to day, see organizations. For what members can do inside one, see roles and permissions.