# 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`](/en/docs/data-components) 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.

:::callout
**Two layers of views.** Developers define _config views_ on a table's `views` array ([Views](/en/docs/table-views)) — the curated, named starting points. End users layer their own _runtime views_ on top, saved per-user. The two coexist: a user can start from a developer view and refine it without touching the config.
:::

## 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](/en/docs/records-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:

```yaml
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](/en/docs/data-components) for the full property reference and [Views](/en/docs/table-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](/en/docs/records-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](/en/docs/records-overview).

## Related Pages

- [Data Components](/en/docs/data-components) — the `data-table` and other components that expose runtime customization.
- [Views](/en/docs/table-views) — developer-defined config views that runtime views build on.
- [Filtering & Sorting](/en/docs/records-filtering-sorting) — the Records API query layer behind runtime filters and sorts.
- [Import & Export](/en/docs/records-import-export) — the CSV import/export API.
- [Records Overview](/en/docs/records-overview) — permissions and the `404` anti-enumeration rule that runtime customization respects.