Overview of Browse Views

A Browse View is a configurable listing of datastore rows for end users. Where the auto-generated data table shows every column an admin has access to, a Browse View lets you tailor what end users see — the columns, the filters, the search controls, and the row-level actions.

Almost every page in an end-user-facing application that displays a list of records is, under the hood, a Browse View. Customer portals, order dashboards, product catalogues, ticket queues — all built from Browse Views configured against the underlying datastores.

Why use Browse Views

Three reasons that come up over and over:

Different roles need different columns and actions on the same datastore. A Customer Service rep looking at orders cares about status and shipping date. A Finance rep looking at the same orders cares about total value and payment status. Two browse views, one underlying table.
End-user portals need a cleaner, more focused listing than the admin view. The admin view shows every column and every action; the end-user view shows a focused subset that fits the user's task.
You want to apply baseline filters. A "My Open Tickets" view filters to the logged-in user's own tickets, in Open status. A "This Week's Bookings" view filters to bookings whose date is within the current week.

What's configurable

For every Browse View you control:

Which columns appear, in what order, with what width.
Which columns are searchable from the global search box.
Which columns are sortable (the heading becomes clickable to sort).
Built-in filter controls — dropdowns, date ranges, toggles — above the table.
Row-action buttons (Edit, View, Delete, plus custom actions).
Pagination size and default sort order.
Baseline filters that always apply ("only open tickets", "only this user's records", etc.).
Empty-state messaging for when there are no rows to display.
Per-role visibility rules (who can see this view at all).

Three real-world Browse Views

Example 1: Customer Order Portal

Datastore: orders. Browse View shown to the logged-in customer:

Columns: Order Number, Date, Status, Total, Tracking Link.
Filters: Status (Open / Shipped / Cancelled), Date Range.
Row actions: View Details only.
Baseline filter: customer_id = current_user_id via row-level security.
Default sort: Date descending (newest first).

Example 2: Internal Sales Dashboard

Datastore: orders. Browse View shown to sales reps:

Columns: Order Number, Customer, Salesperson, Status, Total, Margin.
Filters: Status, Salesperson, Date Range, Total Above.
Row actions: View, Edit, Add Note, Email Customer.
Baseline filter: none (sales sees all orders).
Default sort: Total descending (highest value first).

Example 3: Finance Audit View

Datastore: orders. Browse View shown to Finance:

Columns: Order Number, Date, Customer Name, Payment Status, Total, VAT Calculation, Invoice Sent Date.
Filters: Payment Status, Date Range, Customer.
Row actions: View, Mark Paid, Generate Invoice, Export.
Baseline filter: only paid or pending-payment orders (no draft orders).
Default sort: Date descending.

Screenshot of a rendered Browse View showing a table of orders with custom columns, filter dropdowns above, search box, and row-action buttons per row

Where they're managed

From the Architect Panel → Browse Views. Each browse view is anchored to a single datastore (it can't span tables; for that, use a Custom Query View) and can be surfaced via:

A Friendly URL (e.g. /orders, /my-tickets).
Embedded inside a Page Builder page using a Browse View block.
Linked from a navigation menu or sidebar.
As the destination of a Row Action button on another view.

Tip: Browse Views and Data Layouts work hand-in-hand. A Browse View defines the available columns and filters; a Data Layout saves a specific arrangement of them. Users with appropriate permissions can save their own layouts on a view, and admins can share layouts across teams.