Data isolation
Every organisation’s data is separated at the database row level, so one organisation can never read another’s.
Cadence is used by many organisations at once, but each one is sealed off from every other. One organisation can never read another’s data. This is enforced by the database itself, not by a rule we hope nobody breaks.
Separated at the row level
Every record in Cadence (each time entry, client, project, and member) is stamped with the organisation it belongs to. The database applies row-level security: when your organisation asks for data, it can only ever see rows that carry its own stamp. Rows belonging to anyone else are simply not returned. There is no query, accidental or otherwise, that can reach across that boundary.
By construction, not by promise
The important part is where the boundary lives. It is not a filter bolted on in application code that a future change might forget. It sits in the database and is applied to every customer-facing read, for every organisation, whether the request comes from the app or the public API. The isolation holds because the system is built so it cannot be otherwise, not because we remembered to be careful.
- Each organisation’s data carries its own identity, and queries are scoped to it.
- The database refuses to return another organisation’s rows, by default.
- Every request from the app or the public API is held to this boundary. The only code that operates above it is a small set of server-side jobs (billing, integration sync, and support tooling) which run under tightly scoped service credentials and are never reachable from a browser or the public API.
For how your information is handled more broadly (including exports and deletion) see your data and privacy.