Skip to main content
View as Markdown

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:

Capability What the user can do
Filter Build filter conditions in the toolbar; conditions stack with the developer's base filter.
Sort Reorder by one or more columns ascending/descending.
Group Group rows by a field value into collapsible sections.
Column visibility Show/hide columns via a toggle (surfaced with toolbar: { columnVisibility: true }).
Saved views Save the current filter + sort + field selection as a named, reusable view.
Share Share a saved view with other users.

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 view, filter, sort, toolbar, and groupBy properties:

components:
  - type: data-table
    dataSource:
      table: contacts
    view: active-customers # optional developer-defined starting view
    toolbar:
      columnVisibility: true # surface the column-visibility toggle

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.

  • 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.