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.

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:

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.

This page explains how to use the client-add-organization-id SQL template to backfill the organization_id column on existing application-schema tables and assign clients to organizations.

Warning

Rehearse this on a staging copy before running it in production. This migration has failed in the field: the failure modes and the safeguards that prevent them are listed under Failure modes below.

Download the template:

This page lists the changes in CYPEX v2.0.0 that alter the default behavior of the platform without breaking existing integrations. You should be aware of these changes, but they typically do not require action.

A new row is inserted into cypex.t_config with key password_policy and value:

Info

This screen is Builder → Database in the sidebar. The in-product Setup Guide refers to the same screen as Data Model, and older documentation calls it the model builder or ER editor. All four name the ER canvas documented here.

The next important feature of the admin panel is the ER editor. It allows you to check your ER model, define queries, handle workflows, and a lot more. It is the backbone to handle the data side of your database infrastructure: