The next important step is to define roles. Remember, roles are connected to CYPEX users and represent real database-side users. Role Management lets you manage PostgreSQL database roles and application permissions for your CYPEX platform:

Role Management

Roles define capabilities — what operations a user can perform — which is a separate concern from organization membership, the data scope those operations apply to.

Permissions in CYPEX have two independent dimensions, both required for access:

On the CYPEX side, users and roles are mapped to “login names”. This is done in the Users section of the admin panel:

Users

Active users, Pending SSO, and Rejected SSO tabs. Each row shows the PostgreSQL role, language, active state, and organization membership; use Select organization to filter by tenant.

Info

SSO-specific tabs (Pending SSO, Rejected SSO) and provider configuration are covered in their own section — see SSO Providers for provider setup, and Pending and rejected users for the full state diagram, admin approve/reject/un-reject actions, and audit trail behind these two tabs.

Also note that users are mapped to a database role. This is important, since the database role is what controls access to data — both what a user can do (capabilities) and, since v2.0.0, which organizations they can access. The login name (= email) is merely intended to handle CYPEX logins; permissions to data are managed on the lowest possible level (= PostgreSQL) to ensure consistency between the API, the app, and direct database access.

Access Preview answers one question: given this role, in this organization, what can the user actually reach? It resolves capabilities and data scope together and shows the result, so permission errors surface in the admin panel rather than in a support ticket.

New in v2.0.0. Sidebar location: Access Control → Access Preview. The page itself renders under the heading Effective Access Preview — same screen.

Authorization in CYPEX v2.0.0 is two-dimensional, and both dimensions must agree before a row is returned:

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:

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.