A fixed filter narrows what a Table or List element shows, permanently and invisibly to the end user — unlike search or allowed filters, which the user drives. Use it for “this table only ever shows open tickets” or “only rows belonging to the signed-in user”.

Before v2.0.0 a fixed filter had to be written as a custom expression. v2.0.0 adds a visual rule editor alongside it.

On a Table or List element, in the Filter by section of the element editor. Click Open Filter Builder to open the Filter Builder dialog. The dialog is draggable, so you can move it aside and keep looking at the canvas underneath.

This is the hands-on companion to SSO (the architecture overview). It walks through adding a real provider, signing in through it, and approving the resulting user — using real screenshots captured against a Generic OIDC provider configured against Google, plus the JWT claim trace that applies to every provider identically.

• You need the Organizations administrator role for the target organization (or system admin).
• The host running the SSO Gateway needs outbound HTTPS to the IdP’s discovery, authorization, token, and JWKS endpoints.
• Register the CYPEX callback URL on the IdP side before you save the provider — the default is {app-origin}/auth/{providerType}/callback (e.g. http://localhost:4000/auth/oidc/callback in dev), and the gateway rejects a login whose stored callbackUrl doesn’t match the IdP’s registered redirect URI byte-for-byte.

Under Authentication → SSO Providers → Add provider:

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:

v2.0.0 lets three elements draw on a governed external API connector instead of a database query:

Same canvas, same elements — a different source of data.

A connector must exist and be published before it appears in the designer. Connectors are built and governed on the admin side — allowlist, credentials, definition, then execution enablement. If the picker says “No published connectors are available for this app”, the work is in the admin panel, not the designer. See Connectors and the Connectors setup guide.

CYPEX authenticates users against an LDAP directory as an alternative to local (integrated) accounts — the same mechanism that backs Microsoft Active Directory, OpenLDAP, and any other LDAP v3 server. Before a connection is configured, the page simply confirms that no LDAP authentication is set up yet:

No LDAP authentication configured

Click CREATE to start the connection form.

Fill out the connection settings to establish a connection between CYPEX and your directory:

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.

In CYPEX, an Organization is the unit of multi-tenancy. Isolation is enforced in PostgreSQL by Row-Level Security policies that read the request JWT, not by filters in application code. Application traffic — the generated UI, PostgREST API clients, and the backend’s end-user request path — is subject to the same policies, so reaching the database through a different client does not widen what a user can see.

Organizations are not an authorization system on their own. They add a per-request data scope on top of the PostgreSQL role grants that decide what a user may do.

This page lists the purely additive changes in CYPEX v2.0.0. These do not modify the behavior of existing functionality — they add new tables, functions, indexes, and roles that integrate with the Organizations model.

The central tenant table. Created by the v2.0.0 upgrade with one row already inserted: the Default Organization (organization_domain = 'default').

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: