Browsers

A browser controls presentation. It configures how a dataset is shown to people and what they can do with it. Most browsers belong to a form and render its documents, but a browser can also stand on its own, backed by a view, so a report or dashboard becomes a first-class place in the catalog with no owning form.

A browser defines the list: which columns to show, what to search, the filters and facets to narrow by, and the sort order. It defines the detail view, read-only or editable, and the actions available on a record. And it places itself in the catalog navigation with its own group, icon, and label — nested under the Catalogs area by default, or lifted to its own top-level place when it declares a section.

kind: browser
list:
  search: [name, sku]
  facets:
    - { field: category, label: Category }
  columns:
    - { field: name, label: Name }
    - { field: sku, label: SKU }
  actions:
    create: { label: New, primary: true }
item:
  mode: edit

Browsers also adapt to context. With conditional overrides, the same browser can show different columns, permissions, or a read-only versus editable detail view depending on the situation, for example the role of the person viewing it. A viewer might see a read-only list while an editor gets create, edit, and delete.

Actions are where browsers connect to the rest of the platform. Alongside the usual create, edit, and delete, an action can start a workflow or send a signal to a running one. That is the subject of message-driven processes.