Skip to main content
CYPEX Documentation
Support
v2.0.0 Latest stable release View changelog ->

What is an Organization?

An Organization is the unit of multi-tenancy in CYPEX. It is the data boundary that decides which rows a user can see, insert, update, or delete.

Organizations are not an authorization system on their own. Capabilities — what a user is allowed to do — come from PostgreSQL role grants. An Organization adds a second, independent layer: a per-request data scope on top of those capabilities.

This page is the conceptual reference. For the post-upgrade procedure for assigning clients to organizations, see Detailed organization setup.

Read full post

Capabilities vs Data Scope

The CYPEX permission model is two-dimensional. A request succeeds only when both dimensions allow it:

  1. Capabilities — what the user is allowed to do. Defined by PostgreSQL role grants on queries, functions, and tables.
  2. Data Scope — which rows the user is allowed to act on. Defined by Organization membership and enforced by Row-Level Security policies that read the request JWT.

The two are deliberately independent. Granting a capability and assigning an organization are separate operations, and neither implies the other.

Read full post

Organizations & Row-Level Security

In CYPEX, an Organization is the unit of multi-tenancy. Isolation is enforced in PostgreSQL by Row-Level Security policies that read the request JWT, not by filters in application code. Application traffic — the generated UI, PostgREST API clients, and the backend’s end-user request path — is subject to the same policies, so reaching the database through a different client does not widen what a user can see.

Organizations are not an authorization system on their own. They add a per-request data scope on top of the PostgreSQL role grants that decide what a user may do.

Read full post

Capabilities vs data scope (admin UI)

Info
This page is the admin-panel walkthrough: where each dimension lives in the GUI, and how they combine at query time. For the full conceptual write-up (JWT claims, RLS SQL, the roleType API contract), see Capabilities vs Data Scope under Organizations.

The v2.0.0 access model has two independent dimensions. A request only returns rows when both agree:

DimensionQuestion answeredWhere it’s configured
CapabilitiesWhat is this user allowed to do?PostgreSQL role grants (SELECT/INSERT/UPDATE/DELETE, EXECUTE)
Data ScopeWhich rows is this user allowed to act on?Organization assignment + Row-Level Security

A role with broad capabilities but no organization mapped sees no tenant rows. A role mapped to an organization but with read-only capabilities sees all of that organization’s rows but can’t change them. Neither dimension substitutes for the other.

Read full post

Organizations

Info
This page is the admin-panel entry point for the Organizations screen. The full conceptual and procedural documentation lives in Organizations. This page covers the GUI surface and what an operator can change there.

In CYPEX, an Organization is the unit of multi-tenancy. It is the data boundary that decides which rows a user can see, insert, update, or delete. Organizations are not an authorization system on their own — they add a per-request data scope on top of the existing PostgreSQL role-based capability model. Both dimensions must agree before a row is returned. See Capabilities vs data scope.

Read full post