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:

This page is the operational counterpart to the conceptual pages in the Administration panel section. It targets operators standing up a CYPEX deployment for the first time.

For the why behind the admin IA, see the Administration panel landing and the linked per-section pages. For org / Schema Access operations specifically, see the Organizations setup guide.

Before walking through the procedures, skim the relevant admin pages:

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:

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:

An Organization sits at the centre of two independent mappings, not at the end of a chain. One mapping says which roles belong to the organization; the other says which schemas it may use. Both point at cypex.t_organization, and neither knows about the other:

pg_roles                          cypex.t_module
(login identity, grants)          (schema registry)
    │                                   │
    │  cypex.t_role_organization        │  cypex.t_module_organization
    │  (role_name ↔ organization)       │  (module_id ↔ organization)
    │                                   │
    └──────────►  cypex.t_organization  ◄──────────┘
                  (the tenant boundary)

A user sees a row only when both mappings agree: their role is mapped to the organization, and the schema holding the object is granted to that same organization. Satisfying one without the other produces an empty result, not a partial one.

This page is the operational counterpart to the conceptual pages in the Organizations section. It targets operators who run CYPEX, the PostgreSQL Application Platform, in production and need to perform the four day-to-day jobs: create, edit, and disable organizations; give users access to an organization; configure org-scoped application visibility (Schema Access); and troubleshoot misconfigurations.

For the why behind the model, see the conceptual pages linked below.

Read these four pages before walking through the procedures:

After running the client-assignment migration, walk through the verification queries on this page. If verification fails, follow the rollback procedure.

For every migrated table:

Info

Looking for the conceptual reference (“what is an Organization?”)? See Organizations.

After the v2.0.0 upgrade, every CYPEX deployment starts with a single Default Organization that holds all existing data. This page is the entry point for setting up additional organizations and assigning existing clients / schemas to them.

• You want to split a single-tenant deployment into multiple organizations (one per client, per business unit, or per environment).
• You need to backfill the organization_id column on existing application-schema tables.
• You are operating the cutover from “everything on Default Organization” to “each row tagged with the right organization.”

1. Prepare the existing database — pre-flight checks, downtime planning, smoke-test environment.
2. Enable RLS — the SQL primitives for enabling and configuring RLS on application-schema tables.
3. Assign clients to organizations — uses the client-add-organization-id SQL template.
4. Verify and roll back — verification queries and the rollback procedure if something goes wrong.

• Upgrading to v2.0.0 — for the upgrade-time procedure.
• RLS impact on existing data — for the visibility guarantees before you start.
• Roles and permissions — for the role model you are operating within.

• client-add-organization-id-template.sql — SQL template for adding organization_id to client application-schema tables. See Assign clients to organizations for how to customize and run it. This migration has failed in the field. Read Failure modes before production rollout.