Run through this checklist before applying the v2.0.0 migration scripts. Each item links to the page that explains why it matters.

• Full logical backup with pg_dump:

  ```bash
  pg_dump --no-owner --no-privileges -Fc -f cypex-pre-v2.dump cypex
  ```
  

• Filesystem snapshot of the PostgreSQL data directory, if your infrastructure supports it.

Info

This is the conceptual / architecture reference. For the hands-on, step-by-step walkthrough with screenshots and a real sanitised request/response, see the Setup guide. For the admin-panel GUI reference (screenshots, field-by-field), see Connectors, Connector Secrets, Connector Allowlist, and Connector Enablement.

1. This page — the conceptual / architecture reference.
2. Setup guide — the hands-on E2E walkthrough: rollout, allowlist, credentials, the guided builder, publish, execute, and audit.

A Connector is a governed, server-side definition for calling a third-party REST API and mapping its response into a typed shape a CYPEX application can render — an authenticated CYPEX user’s page can show a table backed by a live external API call, next to tables backed by CYPEX’s own PostgreSQL data.

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:

This page lists the upgrade scenarios that were exercised against the v2.0.0 migration scripts, the result of each, and the explicit answer to the most common question: does RLS change row visibility for existing single-tenant data?

Info

No. RLS does not change row visibility for existing single-tenant data. All existing rows remain visible to all existing users after the upgrade.

The mechanism is described in detail on RLS impact on existing data. The short version: the upgrade creates a Default Organization, maps every existing role to it, and the RLS policies explicitly allow organization_id IS NULL rows to be visible. Existing single-tenant data therefore continues to be readable.

The CYPEX Application Designer is where you configure schema-driven application generation on the PostgreSQL Application Platform.
It turns tracked tables, queries, and workflows into pages and elements you can adjust at low-code speed.

Let’s discuss these elements in more detail and see how they can be used.

The first element is the “menu editor”. It allows you to modify various aspects of the application. It’s of vital importance. It allows you to adjust your menu items. You can also handle software revisions. In this section, we’ll guide you through these features and explain step-by-step what can be done and which purpose these features serve to create even better apps.

This page answers the most common question about the v2.0.0 upgrade:

Info

Does enabling RLS change row visibility for existing single-tenant data?

No. Existing single-tenant data remains visible to all existing users after the upgrade. The migration is designed so that the transition from v1.x to v2.0.0 is transparent for end users at the row-visibility level.

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:

This page describes the v2.0.0 role model and how roles, JWTs, and RLS policies work together to enforce multi-tenant isolation.

All three roles are created as NOLOGIN group roles. Humans (and the authenticator pool) log in as other roles that are granted membership in these groups — they never LOGIN as cypex_admin, cypex_user, or organization_admin themselves.

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.