This page describes the multi-tenant Organizations model introduced in CYPEX v2.0.0 and why PostgreSQL Row-Level Security (RLS) is part of it.

Before v2.0.0, a CYPEX instance was effectively single-tenant:

• One database, one application schema, one set of users.
• Multi-tenancy was emulated at the application layer by filtering rows on a client identifier.
• PostgreSQL row-level security was not enabled on tenant-scoped tables.

This worked, but every enforcement decision lived in application code. A single missing WHERE clause, an ad-hoc reporting query, or a hand-written maintenance script could leak rows across tenants.

This is the hands-on companion to Connectors (the architecture reference) and the individual GUI pages under Administration panel → Integrations. It walks through building one connector end to end, using real screenshots and a real (sanitised) request/response captured while writing this guide.

Two things must exist before you can even save a connector — the order below is enforced by the backend, not just a suggested reading order:

Before you start assigning clients to organizations, walk through this preparation checklist. The procedures on this page are the same shape as the v2.0.0 pre-upgrade checklist, but focused on the post-upgrade multi-tenant setup rather than the upgrade itself.

The procedures here assume the v2.0.0 migrations have been applied. Verify:

v2.0.0 redesigns the login screen. This page describes it from the user’s side: what you see, what to type, and what the messages mean. Administrators configuring providers should start at SSO providers (OIDC) instead.

Two ways in, on one screen:

• Username / Email and Password — sign in with your CYPEX account.
• Or quick sign in: — sign in through your organization’s identity provider (Google, Microsoft Entra, and others), if one is configured.

This page is the mandatory upgrade entry point for CYPEX v2.0.0. It is written for operators who run CYPEX in production and need a single walkthrough that covers every breaking change in this release.

Audience. Read this end-to-end before opening the maintenance window. It links out to detailed pages for each topic; follow every link in the order presented.

v2.0.0 introduces seven platform-level changes. Each one is breaking or behavior-changing for at least one class of deployment.

CYPEX v2.0.0 introduces multi-tenant Organizations with PostgreSQL Row-Level Security (RLS). Tenant isolation is enforced in the database, not by application-layer filters that can be bypassed or misconfigured. This is the most significant schema and permission-model change since v1.0.0.

This section is the canonical place to plan, validate, and execute a v2.0.0 upgrade. It is written from the perspective of factual upgrade behavior: what the migrations actually do, what is additive, what is breaking, and what is behavior-changing.

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.

This page lists the changes in CYPEX v2.0.0 that may require action on the part of operators, integrators, or end users. These are the changes you need to plan for during the upgrade.

The cypex_user role loses INSERT, UPDATE, and DELETE privileges on most tenant-scoped tables. After the upgrade, cypex_user is essentially read-only on those tables, with the exceptions listed below.

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.

This page walks through the SQL primitives for enabling PostgreSQL Row-Level Security on a CYPEX application-schema table and attaching the baseline organization policy.

The v2.0.0 migration already enabled RLS on CYPEX core tables (t_object, t_object_field, t_ui, etc.). This page is about enabling RLS on client application-schema tables during the post-upgrade multi-tenant setup.

Prefer the automated client-add-organization-id SQL template for bulk migrations. Use the primitives below when you need a single-table or large-table (batched) path.