Organisation isolation

Stamped and pinned by the database

No call in the SDK takes an organisation argument. The organisation comes from the credential, and when a row is written a database trigger stamps it from the caller's own claim. A second trigger stops a caller inside one organisation from moving a row to another.

Reads are filtered the same way. A caller sees the rows shared across the project, its own organisation's rows, and those of the organisations beneath it.

The derived data is covered too

Organisation-level policies apply to records, files, users, notes, notifications and events, and to the data derived from them: indexed field values, lookup keys, relationships, geometry, embeddings and access grants. A reader who cannot see a record but can see its indexed values or its embedding has not been kept out, which is why those tables are included. Search runs under the caller's own policies, so a result never comes back for a record the caller could not have read.

Credentials that stand in an organisation

A key can be confined to one organisation when it is created, and that cannot be changed afterwards. Such a key reads its own organisation, the ones beneath it and the shared tier, and writes only its own. A project key can name an organisation per request, and one that is not an active organisation of that project is refused.

What a credential without one reads

A credential that stands in no organisation reads the rows shared across the project and nothing that belongs to an organisation. Reading across every organisation at once is a separate, read-only permission that a public key cannot hold.

The cache

Cached responses are stored per organisation as well as per project, so two organisations' answers never share an entry for a key that is confined to one or names one.