Runtime Data Customization

Developers declare the data model and the pages; end users shape how they see the data. Sovrium gives every data-bound view a set of built-in, runtime customization behaviors — filtering, sorting, grouping, column visibility, saved views, and CSV import/export — so users can tailor their workspace without a developer changing the config.

These behaviors are native platform features, not schema properties. The moment you render a data-table over a table, the runtime customization surface comes with it. There is nothing to enable in app.yaml beyond the component itself; toolbar affordances control which controls are surfaced.

Runtime views

When a data-table is rendered, users can adjust the result set live:

Runtime filters and sorts are applied through the same Records API query layer documented in Filtering & Sorting — the UI composes the filter, sort, fields, and groupBy parameters that the server already understands. A saved view persists that composition under a stable identifier so it can be re-applied with a single click.

The developer-facing entry point is the data-table component and its views, columns, search, toolbar, and groupBy properties. Saved views themselves are declared on the TABLE (tables[].views), not on the component — the component's views property lists which VIEW TYPES (grid, kanban, calendar, …) its switcher offers:

components:
  - type: data-table
    dataSource:
      table: contacts
    views: [grid] # the view types the switcher offers
    toolbar:
      columnToggle: true # surface the column-visibility toggle
      views: true # surface the saved-views dropdown (tables[].views)

See Data Components → data-table for the full property reference and Views for developer-defined config views.

CSV import & export

Users can move tabular data in and out of a table without leaving the page:

• Export the full table or just the selected rows to a CSV file.
• Import a CSV through a mapping wizard that pairs spreadsheet columns to table fields.

Import and export honor the same field-level permissions as the rest of the Records API — a user only exports fields they may read, and only imports into fields they may write. The underlying API paths are documented in Import & Export.

Clipboard operations

Data tables support spreadsheet-style clipboard interactions: copy one or more rows and paste them — including pasting rows copied from an external spreadsheet — with a paste preview before the change is committed. This makes bulk edits feel like working in a spreadsheet while still running every write through the permission-checked Records API.

Permissions still apply

Runtime customization never widens access. Every runtime view, export, import, and clipboard paste runs through the table's RBAC and field-level permissions. A user personalizing their workspace can only filter, read, write, and share data they are already authorized to access — and unauthorized record access returns 404 (anti-enumeration), exactly as documented in Records Overview.

Related Pages

• Data Components — the data-table and other components that expose runtime customization.
• Views — developer-defined config views that runtime views build on.
• Filtering & Sorting — the Records API query layer behind runtime filters and sorts.
• Import & Export — the CSV import/export API.
• Records Overview — permissions and the 404 anti-enumeration rule that runtime customization respects.