Skip to main content
CYPEX Documentation
Support
v2.0.0 Latest stable release View changelog ->

Icon

A standalone display vector glyph rendered from a catalog dropdown or custom expression text path, supporting multi-scale scaling boundaries.

When to use

  • Adding supporting graphic iconography to visually distinguish layout categories or metrics headers.
  • Rendering platform-supported glyph indicators or custom icon expressions within dashboard grids.

What you need

  • Static branding vectors or state flags evaluated dynamically via text box expression workflows.

Examples

  • A 1x1 summary card status indicator rendering a warning symbol based on error flag calculations.
  • An information icon badge aligned inside a visual dashboard heading panel tracking help references.

Avoid

  • Sizing the bounding canvas larger than a 2x2 grid blueprint area, which misuses structural row tracking grids and forces unnecessary white space.
  • Using an independent icon layout block as a standalone interactive link component without descriptive anchor titles.

Editor properties

Configure these in the Application Designer property panel. Group headings mirror the editor where possible. Data Source is where the element gets its rows or field binding (a view/query, a connector operation, or a parent form field). References appear only for view-backed sources and map foreign-key ID columns to readable labels from another view.

Read full post

Release Notes v1.5.0

Features

  • Ability to remove the existing workflow
  • Default table simple filter, able to filter on a numeric column
  • Notifications can be created and sent by the admin to the end-user
  • Ability to see the difference between the query statement and the view statement
  • Added info on the queries that this app already includes
  • Ability to see tables and views list during query creation
  • Simple UI to build a fixed filter with expressions for the table by using autocomplete input elements
  • Ability to use the page load timestamp in custom expression
  • Use lodash in custom expressions
  • Ability to perform any actions via a button
  • Reset an autocomplete input on call button success
  • Show more values in the autocomplete input than visible if values are available

Resolved Bugs

  • Custom query update does not refresh definition.

Read full post

CYPEX Glossary

Abstraction layerIn CYPEX, the query (PostgreSQL view) that sits between base tables and the Application Designer / generated GUI. Applications bind to queries, not raw tables, so the UI stays decoupled from the physical schema. See Query / View below.
FDWForeign Data Wrapper: a PostgreSQL library that communicates with an external data source, hiding connection and fetch details (PostgreSQL Documentation). FDW is not the CYPEX Connector Platform — for governed outbound REST, see Connector and Connectors.
GUIGraphical User Interface. In CYPEX docs this usually means the generated application UI built in the Application Designer (pages and elements bound to queries), as opposed to the admin panel or a command-line / SQL client.
JSONJavaScript Object Notation is a common data format used to exchange data, i.e. between web applications and servers.

JSON is a language-independent data format. JSON file names use the extension .json.

source: Wikipedia

relational model“The relational model (RM) for database management is an approach to managing data using a structure… where all data is represented in terms of tuples, grouped into relations… Users directly state what information the database contains and what information they want from it, and let the database management system software take care of describing data structures for storing the data and retrieval procedures for answering queries.”

source: Wikipedia

v2.0.0 terms

Info
“Module” is deprecated — use “Schema”. In CYPEX, “Module” and “Schema” refer to the same underlying concept: a PostgreSQL schema grouping tables, views, and functions. v2.0.0 introduces Schema Access to grant schemas to organizations. The database column t_module.schema_name and routes such as /admin/organization-modules still use the older “module” identifier; new prose should say “Schema”.
Access PreviewThe admin tool that resolves Capability and Data Scope together for a given role and organization, listing the apps, queries, functions, and state transitions actually reachable. Full reference: Access Preview
Access token / Refresh tokenThe pair that bounds a v2.0.0 session. The access token is a short-lived JWT (15 minutes by default) carrying the tenancy and authorization claims RLS reads. The refresh token is longer-lived, cookie-only, and never readable by application code; each renewal re-checks the user in the database, so disabling a user ends the session at the next refresh rather than at token expiry. Full reference: Sessions and tokens
Application / Application DesignerAn Application is a deployable CYPEX app generated from the data model (sidebar: Builder → Applications). The Application Designer is where you configure pages, menus, and elements bound to queries and workflows. Full reference: Application Designer
CapabilityWhat a user is allowed to do — SELECT, INSERT, UPDATE, DELETE, EXECUTE — defined by PostgreSQL role grants, as opposed to Data Scope (which rows). Capabilities are granted on queries (views), not base tables. The JWT isSuperAdmin / isOrganizationAdmin flags do not grant capabilities; they are read by RLS policies and belong to Data Scope. The admin-panel menu label is Roles & Capabilities. Full reference: Capabilities vs Data Scope
ConnectorA governed, server-side definition for calling a third-party REST API and mapping its response into a typed shape a CYPEX application can render. Lives under admin Integrations (enablement, allowlist, credentials, definitions). Gated by enablement, an outbound host allowlist, and org-scoped credentials; every execution is audited in the shared permission audit log. Connector definitions and credentials are RLS-protected by Organization but deliberately not exposed through PostgREST. Full reference: Connectors
Custom expressionA JavaScript expression stored in an element's configuration, written with the @@expression: prefix and evaluated against application state to make a property dynamic — visibility, disabled state, computed labels, row highlighting. Expressions are evaluated client-side and are not a substitute for a permission check. Full reference: Expressions
Data ScopeWhich rows a user is allowed to see or change, as opposed to Capability (what operations they're allowed to perform). Scope comes from the role→organization mappings in t_role_organization and is enforced by Row-Level Security — not from the role name alone. The admin-panel sidebar label is Organizations (under Access Control); some docs also say Organizations & Data Scope for the same dimension. Full reference: Capabilities vs Data Scope
Default OrganizationThe organization created automatically when upgrading from v1.9.x (organization_domain = 'default'). The upgrade maps every pre-existing module and every cypex_user / cypex_admin member role to it, and creates a cypex_default virtual module as its primary, so existing single-tenant data stays visible without a backfill. Full reference: Upgrade to v2.0.0
Element / Element typeThe unit of composition in the Application Designer. An element type is a reusable building block (table, form, chart, file upload, GeoJSON viewer, action button); an element is one configured instance of a type placed on a page and bound to a query field. Element types are selected automatically when a default application is generated, based on the column's PostgreSQL data type. Full reference: Application Designer
EntityIn the Model Builder (Builder → Database), an entity is a table (or relation) shown in the Entities panel and on the ER canvas. Generating a default query, defining a workflow, or enabling auditing starts from an entity. Full reference: Database (Model Builder)
External APIA third-party REST API outside CYPEX's own database — what a Connector under Integrations calls. Distinct from CYPEX's generated data API (PostgREST), browsed in the admin panel as REST API. Release notes may call the feature area the "Governed External API Connector Platform"; day-to-day copy uses Connectors / Integrations. Full reference: Connectors
Identifying columnThe single column a query uses to address one row — the basis for form binding, sub-form navigation, page links, and chart drill-down. Chosen from the primary key when a default query is generated, falling back to a UNIQUE index on a NOT NULL column. Must be a single column: composite keys cannot identify a row in CYPEX. Full reference: Terminology
IdP (Identity Provider)The external system (Google, Microsoft Entra, Auth0, Keycloak, JumpCloud, …) that authenticates the end user on CYPEX's behalf before handing back the identity claims the SSO Gateway consumes. Full reference: SSO
JWT claimsTenancy and authorization claims on the CYPEX access token that RLS helpers read: org_id (active organization), organization_ids (all accessible organizations), isSuperAdmin, and isOrganizationAdmin. Full reference: What is an Organization?
LDAPDirectory authentication (Active Directory, OpenLDAP, or any LDAP v3 server) configured under admin Authentication → LDAP. Coexists with local login and OIDC SSO; role mapping is configured separately from SSO Providers. Full reference: LDAP
Module (deprecated)Legacy synonym for Schema — see the deprecation note above. Still appears in database identifiers (t_module.schema_name, t_module_organization) and route paths that predate the v2.0.0 relabeling; do not use it in new prose.
OIDC (OpenID Connect)The identity protocol the SSO Gateway uses for federated login. The admin UI offers five provider types: Generic OIDC, Generic OAuth2, Google, Microsoft, and GitHub. Other IdPs (Keycloak, Auth0, JumpCloud, Entra via discovery, …) use Generic OIDC; Google, Microsoft, and GitHub have dedicated gateway strategies. A successful sign-in does not by itself grant CYPEX access — see SSO user lifecycle (pending / active / rejected). Full reference: OIDC setup guide; lifecycle: Pending and rejected users
OrganizationThe unit of multi-tenancy in CYPEX: the data boundary that decides which rows a user can see, insert, update, or delete, enforced by PostgreSQL Row-Level Security keyed on JWT organization claims. An Organization is not an authorization system on its own — see Capability and Data Scope below. Full reference: What is an Organization?
Permission audit / Connector AuditGovernance evidence for permission, role, organization, and connector decisions in cypex_log.t_permission_audit_log. Connector Audit (Monitor & Audit) is that same log filtered to connector EXECUTE_* outcomes — not a separate audit system. Distinct from Table Audit History (cypex.t_history) and User Audit Trail. Full reference: Governance evidence; Connector Audit
PostgREST / Data API (REST API)CYPEX exposes queries (views) as a generated REST API via PostgREST, with JWT auth and RLS. In the admin panel the explorer is labeled REST API (Data & Content). Sibling to Connectors: this API serves your database; Connectors call external APIs. Full reference: REST API
Query / ViewIn CYPEX, a query is stored as a PostgreSQL view. Queries are the abstraction layer applications and the Data API bind to; default queries are generated per entity in the Model Builder. Full reference: Database (Model Builder)
Row-Level Security (RLS)PostgreSQL feature that filters which rows a session can see or change. In CYPEX, RLS policies use JWT claims (org_id, organization_ids, admin flags) so Organization membership becomes the data boundary. Full reference: What is an Organization?
Role typeThe classification chosen when a role is created, new in v2.0.0: System Administrator (system_administrator) reaches every organization; Organization Administrator (organization_administrator) reaches only its mapped organizations; Organization Member (organization_member, the default) is confined to its active organization. The two organization types require at least one organization assignment — a rule enforced on the API path, not by a database constraint.

No role type bypasses RLS. Administrative reach is written into the policies themselves as cypex.is_admin() and cypex.is_organization_admin() clauses, which read the JWT. Every access, administrative included, is still decided by a policy in the PostgreSQL engine — no CYPEX role carries the PostgreSQL BYPASSRLS attribute.

API note. The name roleType carries two unrelated meanings in the CYPEX API. On role creation and organization-mapping requests it is the classification above (system_administrator / organization_administrator / organization_member). On the role list endpoint it is a list filter with the values system and user-defined, which distinguishes CYPEX's own roles from ones you created and says nothing about administrative reach.

Full reference: Roles & Capabilities

Schema AccessThe admin control that decides which schemas (modules) an organization may use — the coarsest of the three access controls, sitting above Capability and Data Scope. An organization with no grant sees nothing in that schema regardless of role or RLS policy. System Administrator only. Full reference: Schema Access
SchemaA PostgreSQL namespace grouping tables, views, and functions. In the CYPEX admin panel, granting a Schema to an Organization is done on the Schema Access page (new in v2.0.0 — see Module above for the deprecated synonym). Full reference: Schema Access
SSO GatewayThe standalone service introduced in v2.0.0 that handles federated login, with its own sso_gateway PostgreSQL schema and its own key-encryption key (.sso_kek). It requires Redis and refuses to start without its key material. Providers are configured per organization, not globally. Full reference: SSO
SSO user lifecycleEvery federated identity in sso_gateway.t_sso_user_map is pending, active, or rejected. Pending identities need admin approve/link (or a matching role-mapping / auto-link rule); rejected identities stay blocked until un-rejected. Full reference: Pending and rejected users
SSO (Single Sign-On)Federated login to an external identity provider, handled by CYPEX's standalone SSO Gateway microservice. SSO sits alongside local username/password login and LDAP rather than replacing them; each Organization can enable one or more providers independently. Full reference: SSO
State columnThe single column on an entity that holds its workflow state. An entity has either no state column or exactly one — combined or multiple state columns are not supported. The column must be text-like or identifier-like (text and variants, uuid, the integer family, numeric, or a user-defined type such as an enum); boolean, date and time, JSON, geometric, and interval columns are rejected. Full reference: Workflows & State Transitions
System rolesThe PostgreSQL roles CYPEX installs and relies on. authenticator is the low-privilege login role PostgREST connects as, switching into a request's role per JWT. anon is the role for unauthenticated requests. cypex_user and cypex_admin are the template roles application and administrative roles inherit from. organization_admin inherits cypex_admin and is the basis of the Organization Administrator role type. These are visible in Roles & Capabilities but should not be edited directly. Full reference: Roles & Capabilities
Table Audit HistoryRow-level change history for a tracked table, written by a trigger into cypex.t_history: the operation, the before and after row images as JSONB, the timestamp, and the PostgreSQL user that made the change. Because the trigger fires in the database, changes made outside CYPEX are recorded too. Enabled per entity in the Model Builder; the admin-panel page is Monitor & Audit → Table Audit History. Distinct from the Permission audit log and the User Audit Trail. Full reference: History tracking
Workflow / State transitionA CYPEX state machine on an entity: named states on a state column, and the transitions permitted between them (for example draft → review → published). A workflow can be enforced, in which case CYPEX writes a CHECK constraint for the valid states and a row trigger for the valid transitions, so invalid changes are rejected regardless of the client. Each transition can carry an ACL of PostgreSQL roles, a pre-function that decides the resulting state, a post-function for side effects, and a validity period. Access Preview lists which transitions a role can fire in a given organization. Full reference: Workflows & State Transitions

Internal Link Button

A styleable navigation layout link or button component designed strictly for routing internally between local workspace page templates.

When to use

  • Navigating users cleanly between different pages or routing dashboards inside the current application workspace environment.
  • Providing simple routing triggers (e.g., standard ‘Back to List’ cancel paths or detail page redirects) without triggering secondary transactional database operations.

Examples

  • A ‘Cancel’ secondary action button nested within a form layout that returns the user safely to the main dashboard directory.
  • A compact icon-only navigation shortcut placed inside a data grid header routing users straight to a detailed analytics overview tab.

Avoid

  • Navigating to third-party web portals or external addresses outside the current platform domain, use the external_link_field instead.
  • Configuring complex multi-step mutation procedures or API transactions directly on this element, use default_call_button or action_button instead.
  • Allocating visual footprints taller than 1 grid row unit high, which breaks visual layout conventions.

Use instead

Read full post

Release Notes v1.4.1

Features

  • Migrate an app definition Now, it’s possible to migrate apps that have versions different from the latest ones.

  • Ability to get information about the available DATA API endpoints

  • Usability improvements:

    • Add an ability to inject custom CSS styles into an app
    • Add an ability to toggle a modal dialog via an action
    • Fetching query data now available without a visible element
    • Preview all columns of a table
    • Generate pages for specific queries in the app
    • Query information contains which pages were generated
    • Preview the data of an existing query and of a database table
    • Ability to display a custom error message in a form
    • Table reload on form success
    • Data preview for a query in edit mode
    • Ability to delete a role
    • Permissions editing of a custom query
    • Ability to render different elements if the advanced conditional element is not visible
    • Add row actions to an existing table
    • Page title moved to the appbar

Resolved Bugs

  • Controlled date input/ date-time input cannot be cleared once a value is set

Read full post

Internal Link Field

A data-aware detective anchor hyperlink that looks like standard underlined body text by default, pulling specific row criteria parameters to compute dynamic page transfers.

When to use

  • Navigating users dynamically to specific record detail views by extracting unique row variables from the current screen context (e.g., clicking a specific product row to go to its unique page).
  • Building smart, data-aware text links inside tables, list rows, or informational cards that require identifier parameter interpolation.

What you need

Requires binding a relational query name source, choosing the underlying primary target identifier column, and passing an active evaluation expression to capture runtime row values.

Read full post

Release Notes v1.3.0

Features

  • Install CYPEX on an existing database

    It is now possible to run CYPEX with an existing PostgreSQL database rather than using the one shipped with CYPEX by default

  • Usability improvements:

    • Display the table count within a schema
    • Display the table disk size in the entity tree
    • Add the ability to edit the title of a query
    • Display runtime errors in the query preview when creating or editing a query
    • Display the query statement while in edit mode
    • Add the ability to upload an image in the image element configuration

Resolved Bugs

  • Nested form cannot be set as data source in input elements

Read full post

Default Interval Field

A read-only single row duration string that outputs individual segmented time measurements separated by unit letters based on configuration toggles.

When to use

  • Displaying specific time durations or elapsed period chunks (e.g., ‘3y, 5m, 3d’) cleanly in the interface.
  • Rendering structured ISO 8601 duration intervals parsed from technical database columns into human-readable segmented blocks.

What you need

Accepts a raw ISO 8601 interval duration text string (e.g., ‘P3Y5M3DT3H3M3S’) or an expressional codebase script returning equivalent data logs. Alternatively can be hardcoded manually using individual numeric inputs across six chronological time parameter buckets.

Read full post

Json Field

A read-only interactive code viewer tree containing collapsible object nesting hierarchies and visual type-specific markers.

When to use

  • Presenting structured data payloads, complex nested records, or configuration logs in a clean, expandable tree structure.
  • Providing developers or administrative users with readable debugging viewports that indicate property data types (string, number, boolean) explicitly.

What you need

Sourced strictly through custom expressions capable of invoking direct structural data objects, dynamic API queries, or active field value references.

Read full post

Label Field

A short static caption, used to title a group of elements that have no heading of their own.

When to use

  • Naming a section of a form or a block inside a Grid.

Examples

  • A ‘Shipping address’ caption above an address block.

Avoid

  • Using it to label a single input — inputs carry their own label, and a second one is read twice by screen readers.
  • Using it for values that change; it holds fixed text.

Use instead

Read full post