InfoThis 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:
Data Model — ER overview
The Data Model canvas groups tables by schema and shows the foreign-key relations between them. The Entities panel on the right lists every table and view in the current schema.
Use the zoom controls and the fit-to-view icon on the right of the canvas to navigate a large ER model quickly. Tables and views in the same schema are grouped together in a box; click any entry in the Entities panel to jump straight to it.
Every Data Model view can be scoped to a single Organization using the Select organization dropdown next to the page title. This does not change the underlying schema — it filters what you see to the tables, queries, and permission defaults relevant to that tenant:
Select organization
Picking an organization scopes the ER canvas, and the Organization field on Generate Default Query / Generate Default Queries, to that tenant.
InfoWhy this matters. CYPEX applications are multi-tenant: each Organization is a data boundary enforced by PostgreSQL Row-Level Security. The Data Model editor is schema-level and shared across organizations, but default queries and their permissions are generated per organization so that the resulting app respects the active tenant’s data scope. See Organizations and What is an Organization? for the full model.
Each relation has “three dots” on the right side of its box. Click those dots to configure the relation — generate a default query, define a workflow, set a default lookup, enable auditing, or inspect table details:
Table context menu
The three-dot menu on a table exposes Generate Default Query, Workflow, Default Lookup, Auditing, and Table details. Generate Default Query is disabled once a table already has one.
On foreign tables (FDW), Workflow and Auditing are not offered — both require DDL on the local relation.
In the Entities panel, expand a schema to see every table it contains, and toggle the eye icon to hide or show that schema on the canvas — both tables and views appear and disappear together. The same toggle also excludes the schema from bulk query generation:
Entities panel
Expanding a schema in the Entities panel lists its tables. The eye icon toggles the schema's visibility on the ER canvas and its inclusion in query generation.
CYPEX relies heavily on primary keys, foreign keys, and unique constraints to drive default rendering — always index both sides of a foreign-key relation to keep queries efficient.
Often you simply want to see and edit a table. A default query is the fastest way to make that happen. Open the context menu and click Generate Default Query:
Generate Default Query
Choose the target Organization, set a Title and Group, then grant SELECT / INSERT / UPDATE / DELETE per role in the Permission Table.
Set the Title; Name is derived from it automatically and is read-only, because it becomes the name of a view in the cypex_generated schema. Group is optional and only organizes the query list. The Organization field scopes the generated query to a tenant, and the Permission Table decides what the rendering engine is allowed to build: without INSERT permissions, for example, you will not see input forms. The admin panel allows one default query per relation — the menu entry is disabled once one exists.
Every query, default or custom, is a view in cypex_generated. That schema is the one PostgREST exposes, so the view is also the REST resource your application reads and writes through, and the grants you set in the Permission Table are the PostgreSQL grants PostgREST enforces at request time.
To generate default queries for every eligible table at once, use the Generate Default Queries button in the top toolbar. It offers the same Organization scoping, plus a searchable schema-and-table picker:
Generate Default Queries (bulk)
Bulk-generate default queries across schemas. Only tables that do not yet have a default query are listed, and schemas hidden with the eye icon are left out of the run.
Only tables that do not yet have a default query are listed, and schemas you have hidden with the eye icon in the Entities panel are excluded from the run.
The next important menu entry opens the workflow editor. As previously stated, workflows are a core component of CYPEX. In a simplified world, tables translate to forms and tables — workflows are in charge of buttons. Workflows add “life” to your otherwise static application.
Workflows are associated with tables and are defined on a state column. A workflow consists of states and state changes: states are valid entries in the state column, while state changes are UPDATEs moving states from one value to another. The validity of those changes is guaranteed by the database engine.
From the table context menu, click Workflow and choose the column that holds the state information. Only columns of a suitable type are offered, and the column should have a default value. CYPEX reads the distinct values currently present in the table and offers them as candidate states:
Select the workflow column
CYPEX inspects existing row values (here: process, pending, done) and offers them as valid states. Check 'Create Transitions to All' to auto-generate every transition between them.
Once you save, CYPEX opens the graph editor. If you did not check “Create Transitions to All”, states are listed but not connected — you draw the transitions by hand. With it checked, CYPEX produces every state change automatically, shown as directional arrows between START, each state, and END:
Workflow editor
smi.t_transactions.status with three states (process, pending, done) and every transition pre-wired between them and START/END.
Enforcement Disabled / Enabled (top toolbar) controls whether the workflow is only metadata or is actually applied to the table. While you design a workflow, enforcement stays disabled: states and transitions live only in the CYPEX configuration tables, and the core relation is untouched. Enabling it adds a CHECK constraint restricting the state column to the modelled states, plus a BEFORE INSERT OR UPDATE OR DELETE trigger. The trigger requires a transition from START to insert a row and a transition to END to delete one, and on UPDATE it permits only modelled transitions and checks the caller’s role against that transition’s permissions.
Enabling fails if the table already contains values outside the workflow — clean the data first. Two operational caveats: CYPEX drops the table’s existing CHECK constraints with CASCADE before re-applying, so hand-written CHECK constraints on the same table do not survive; and a failed activation leaves the table unconstrained until you fix the data and enable it again.
Use New State to add a state to the workflow. Click a state’s edit icon to rename it, add a description, and decide whether rows may be edited while in that state. Turning on Allow State Updates reveals Permission Settings, where you pick the roles allowed to edit rows in that state; Manage Permissions jumps to the matching role in Access Control:
Edit State
Editing a state: title, description, the Allow State Updates toggle, and role-scoped Permission Settings, plus a link to the centralized Access Control roles page.
To create a transition, drag an arrow from one state to the state you want to reach. Click an existing transition to edit its title and its own Permission Settings — the text you set here is what the rendering engine uses to label the resulting state-change button:
Edit State Transition
A transition from PROCESS to END State, with a title CYPEX uses to label the button and per-transition Permission Settings.
Workflows serve a purpose: they ensure the application only allows the changes the business process actually supports. Once modeled and enforced, the GUI will not offer state changes that fall outside the graph you built.
Every relational model has a significant number of “id” columns, and nobody wants to see raw numbers in the GUI. Default Lookup lets you pick the column that should represent a row wherever it appears as a foreign-key reference:
Default Lookup
Selecting the Default Lookup column for smi.t_countries. CYPEX recommends a unique, human-readable text column.
CYPEX inspects your ER model and key relations so the default renderer can automatically generate the app the way you want it to look.
Security and change tracking are a key concern for most enterprise customers. Auditing automatically tracks every INSERT, UPDATE, DELETE, and TRUNCATE on a table — including changes made directly against the underlying table, not only through the GUI:
Auditing
Enabling auditing deploys the tracking infrastructure automatically. Historical data is saved to cypex.t_history and can be reviewed in the Audit section. Enabling auditing can impact performance.
Turning tracking off is equally easy — reopen the same dialog and disable it. Disabling removes the triggers but keeps the history already recorded.
Looking at the ER model alone does not always give you everything you need. Table details opens a three-tab view of a relation. The header always shows estimated rows, data size, total size, and column count:
Table details — Overview
The header carries estimated rows, data size, total size, and column count. The Overview tab adds the table's COMMENT, Column Statistics, and Keys & Relationships.
The Overview tab shows any COMMENT stored on the table, then a Column Statistics card (Total Columns, Required (NOT NULL), Nullable, Unique Constraints), then a Keys & Relationships card. Columns lists the full column definitions.
Switch to the Data preview tab to see a sample of the actual rows. Only a subset is shown, to keep performance predictable — this is enough to understand the data before writing a query, not a replacement for a full SQL client:
Table details — Data preview
A read-only preview of the table's rows, useful for getting a feel for the data before writing a query.
The Queries panel lists every query available in the current schema. Use the Default / Custom toggle to switch between generated and hand-written queries, and narrow the list with the search box or the By Role filter:
Queries panel
Filter queries by name or by role and switch between Default and Custom. The Show Menu icon holds Create Query, Generate Default Queries, Delete All Queries, and Create Query Group.
You can edit a default query’s title, group, and permissions from its edit icon; its SQL definition is generated and stays fixed. To write a custom query, open the Show Menu icon and choose Create Query — the same menu also holds Generate Default Queries, Delete All Queries, and Create Query Group.
Raw tables are often not enough to build an application — in most cases data must be pre-processed before it can be fed to the graphical user interface. This is exactly what queries are for.
- Applications — predict applications from the data model.
- Audit — table-level audit trail.
- Organizations — the admin-panel entry point for multi-tenancy.
- Organizations setup guide — create, edit, and assign organizations.
- Schema Access — fine-grained module/schema grants per organization.