Table

A data table with search, sorting, filters, optional row selection, foreign-key label resolution, and row/create actions.

• Presenting large relational datasets, data logs, or multi-attribute list rows in a structured grid layout.
• Providing interactive tabular views complete with sorting priorities, row selection states, foreign key display mappings, and dynamic filtering tree builders.
• Offering full CRUD operational tables with built-in row actions (Edit, Details, Delete) and a dedicated record creation button.
• Use Table when the page must browse many records from a query/view and users need scanning, sorting, filtering, pagination, or row-level actions.
• Use Table for list pages, work queues, back-office administration, approval inboxes, catalogs, and search results where each row represents one business record.
• Use Table when the page consumer may need to define runtime filters from the UI, not only fixed filters defined by the page builder.
• Use Table when a create flow, details flow, edit flow, or delete flow should stay close to the data list.

A useful table requires a valid dataSource.viewName, and it becomes much more reliable when the source also exposes a stable identifier field. References are optional but strongly recommended whenever the source contains foreign IDs that should be rendered as readable names. Column behavior is split across the table itself and its header/body child elements: the table owns source/filter/selection/paging/action scaffolding, while each column is defined by paired child elements in the header and body slots.

• List-shaped data with many rows and a stable identifier column.

• Queries/views whose fields have meaningful labels and data types, so filterable columns and generated columns are understandable.

• Datasets that benefit from sort order, pagination, incremental search, and user-defined filtering.

• Datasets with foreign keys that can be resolved through references into display names.

• Records that may expose row metadata such as canUpdate, canDelete, or workflow state.

• A valid source view/query is required before the table can load rows and before most editor dropdowns can offer meaningful options.

• Prefer a stable identifier column via dataSource.identifierName so row selection, row actions, and navigation can reliably target one record.

• If the source returns foreign IDs such as airline_id, define references so body columns can resolve readable values such as airline_name.

• If the table participates in workflow or guarded row actions, ensure the dataset and metadata support permission-aware actions and optional state rendering.

• A user list with auto-refresh, company-name references instead of raw IDs, multi-row selection, and row actions.
• An operations table of flight logs where airline_id resolves to airline_name through a reference view.
• Reference-heavy datasets where the source query returns IDs but the UI should display human-readable names from referenced views.
• Selection dialogs where the user must pick one row or multiple rows and another element consumes elements..selected.
• CRUD index pages that expose a top-level Create button and row-level actions for details, edit, and delete flows.
• Operational dashboards where a list refreshes on an interval and users need a quick simple filter plus a richer advanced filter.

• Squeezing a primary list into a narrow layout block, which creates severe horizontal scroll friction and truncates toolbar utility controls.
• Configuring foreign reference tables without mapping identifier IDs to display names (e.g. leaving raw numeric airline_id visible instead of mapping to airline_name).
• Confusing the designer’s prebuilt ‘Filter by’ rules with the runtime end-user custom filter tool.
• Do not use Table for a single record detail screen. Use a form or detail-oriented element when the user should focus on one object at a time.
• Do not use Table if no valid dataSource.viewName is available. Most dependent editor options do not become meaningful until the source view is known.
• Do not use Table to present a tiny fixed dataset with no filtering, sorting, or actions if a simpler display element communicates the information more clearly.
• Do not keep foreign-key IDs visible to end users when a readable referenced label is available. Prefer references plus body-column expressions that resolve names.
• Do not enable row selection unless another part of the page or workflow actually consumes the selected row or rows.
• Do not hide core identifying columns and also omit references, because users can lose the ability to understand what each row represents.

Use instead

• Form — Prefer a form when the page focuses on creating, editing, or reviewing one record rather than scanning many rows.
• Data Display — Prefer data display cards or KPI elements when the page should summarize a few values instead of showing a record grid.
• List — Prefer a list when each row needs a richer card-style layout rather than a dense multi-column grid.

Pairs well with

• Table Header Cell — The only element type the header slot accepts. Each header cell is paired with a body element to form one column, and owns that column’s field, label, alignment, width, and sortable flag.
• Internal Link Button — Common row action used to implement details or edit navigation inside the Actions column.
• Delete Button — Built-in row delete action commonly hosted in the Actions column and usually guarded by row metadata.
• Button Group — Hosts row action elements in the table body when the Actions column is enabled.

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.

Inside createButton: (createButton)

ColoroptionalOne of: primary, secondary, success, error, warning, info, default, lighter, disabled, white, black (or not set)

Visual color of the Create button. Can be a literal or an expression.

Choices

• primary
• secondary
• success
• error
• warning
• info
• default
• lighter
• disabled
• white
• black

Good to know

• Prefer primary for the page’s main create action so it reads as the dominant control.

Default: none

DisabledoptionalCustom expression (yes/no)

When true, the control cannot be edited.

Example false

Default: none

EnabledrequiredYes / no or Custom expression (yes/no)

Controls whether the top Create button is available. Can be a boolean or an expression.

Avoid

• Do not show a Create button that navigates nowhere or opens a page the user cannot complete.

Default: false

IconoptionalText

Configuration for icon.

Default: none

Is IconoptionalYes / no

When false, the button shows label plus icon. When true, the control is rendered as icon-only.

Default: none

Link TorequiredSettings group

In-app navigation target (page and parameters).

Default: {"pageId":"","params":{}}

SizeoptionalOne of: small, medium, large

Size of the Create button.

Choices

• small
• medium
• large

Default: none

VariantoptionalOne of: outlined, contained

Variant of the Create button.

Choices

• outlined
• contained

Default: none

• Minimum size: 4 × 4 grid cells (width × height).
• Default size when dropped on a page: 12 × 6.
• Shrink below the default only for a secondary or embedded table, such as a picker inside a modal. A primary business list needs the full width to avoid truncating columns and the toolbar.

• createButtonLabel — Label shown on the table-level Create button next to the simple filter area.

Tables should preserve clear column labels, obvious row focus/selection states, and understandable action labels. Filtering, paging, and create actions should remain operable without relying only on visual cues.

• Ensure row selection and row actions are reachable by keyboard when enabled.
• Do not rely on hover-only affordances for important actions.
• Keep filter and create controls reachable before dense table content.
• Column labels should remain meaningful because they carry most of the structure for assistive technologies.
• Icon-only create or row-action buttons need accessible labels that communicate the action clearly.

Other parts of your app can read live values from this element in custom expressions:

To use one of these, open the property you want to drive on the other element, switch it to expression mode in the Expression Editor, and enter:

1

elements.myTable.selected

Replace myTable with this element’s unique id. Select the element in Application Designer and copy the id chip at the top of the right-hand property panel.

This container accepts nested elements in these slots:

graph TD
  root["default_table"]
  root --> header["header slot"]
  root --> body["body slot"]

Drag this element into one of these containers:

• Conditional Container
• Form
• List
• Modal Dialog
• Tabs

• Grid (content slot) — Most primary list pages place the table directly in a grid and give it the dominant width on the page.
• Tabs (content slot) — Use inside tabs when the list is one subsection of a broader detail or administration workflow.
• Modal Dialog (content slot) — Works as a picker inside a modal, but reduce visible columns and keep selection behavior explicit.