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.

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.

The column list is the bulk of a Browse View's configuration. For each column you decide what's shown, how it's rendered, how wide it is, and whether the user can interact with it (sort, search, filter).

Per-column settings

Open a Browse View and find the Columns section. Add a column for each field you want shown; for each column configure:

• Field — which datastore column this Browse View column reads from.
• Display Name — column heading (overrides the datastore's Friendly Name if you want to be more specific in this view's context).
• Width — pixel value (150px) or percent (10%).
• Searchable — whether the global search box matches against this column.
• Sortable — whether the column heading is clickable to re-sort.
• Default Sort — whether this column drives the default sort order, and whether ascending or descending.
• Display Format — optional template using ##AMDATA_fieldname## tokens to combine multiple raw values into one display.

Display Format examples

The Display Format setting is one of the most powerful column features. Three patterns that come up:

1. Combine name fields into one column

Format: ##AMDATA_firstname## ##AMDATA_lastname##. Renders "Jane Smith" in a single column even though firstname and lastname are separate fields on the datastore.

2. Embed multiple values with formatting

Format: <strong>##AMDATA_companyname##</strong><br/><small>##AMDATA_email##</small>. Renders the company name in bold with the email underneath in smaller text — a two-line column showing both fields.

3. Conditional display

For more complex logic, use a Custom PHP Code field as a derived column. The PHP can inspect the row's data and return whatever HTML you want, including conditional content ("Overdue" badge on tickets past their SLA, status icons coloured by state, etc.).

Hidden columns for context

Sometimes you need a column included in the underlying query (for example to enable a row-action URL that needs the row's ID) without showing it in the table. Set its Width to hide — the column is fetched into the result set but not displayed.

This pattern is essential when row actions link to URLs like /orders/##AMDATA_id## — the ID needs to be in the row data even if you don't want to show it as a visible column.

Three real-world column configurations

Example 1: Customer list for sales reps

• Company Name (200px, sortable, searchable).
• Primary Contact (combined firstname + lastname via Display Format, 150px, searchable).
• Email (200px, searchable).
• Total Spend (100px, sortable, right-aligned).
• Last Activity Date (120px, sortable).
• Tags (200px, multi-pill rendering).
• Status (80px, badge-style rendering via Custom PHP).

Example 2: Order queue for fulfilment team

• Order Number (100px, sortable).
• Customer Name (150px, searchable).
• Items (combined count + summary via Display Format, 300px).
• Status (80px, badge).
• Required-by Date (120px, sortable; rows highlight red if overdue via row-styling).
• Action (hidden column carrying the row ID for the action URL).

Example 3: Ticket dashboard for support team

• Reference (80px, sortable).
• Subject (300px, searchable; truncated to one line).
• Customer (150px).
• Assignee (120px).
• Priority (60px, sortable, coloured badge).
• SLA Status (combined SLA-due + elapsed-time via Display Format, 120px).
• Last Update (120px, sortable).

Tip: Keep column count under 7 if possible. Tables with more columns become unreadable on smaller screens — the human eye struggles to scan beyond about 7 vertical columns. If you need more data per row, consider expanding rows to show detail rather than adding more columns.

Beyond the global search input, Browse Views support dedicated filter controls above the table — dropdowns, date pickers, toggles, range sliders. Configure them once and your users get a far better browsing experience than typing into a generic search box.

Why filters beat search

Search is universal but blunt. The user has to know what they're searching for and type it accurately. Filters are domain-specific and forgiving — a Status dropdown lists the available options so the user doesn't have to remember them; a Date Range picker constrains valid input; a toggle is binary so there's no typing involved.

For any browse view where users will return repeatedly to similar subsets of the data, filters give a much better experience than search. Add both; users will gravitate to filters once they discover them.

Adding a filter

In the Browse View's configuration, find the Filters section and click Add. For each filter specify:

• Field — which datastore column the filter narrows on.
• Display type — dropdown (single-select or multi-select), date range, search box (textual contains-match), toggle (boolean on/off), range slider (numeric min/max), pills (visual multi-select).
• Default value — what the filter is set to when the user first lands on the view.
• Label — text shown above the filter control.
• Width — pixel or percent value for the filter's horizontal space.

Stacking filters

Multiple filters are AND-combined. A user can pick a Status, a Date Range, and an Owner — and the resulting list reflects all three constraints. Filters with no selection contribute nothing (they pass everything through).

The platform's filter UI clearly shows which filters are active, with a quick "Clear all" button to reset. Active filter counts also show in the URL, so users can bookmark or share specific filtered states.

Three real-world filter sets

Example 1: Customer browse view (sales)

• Status (dropdown) — Active / Inactive / All. Default: Active.
• Owner (dropdown) — list of salespeople. Default: All.
• Total Spend Above (number) — Default: blank.
• Last Activity (date range) — Default: blank.
• Tags (multi-select pills) — Default: blank.

Example 2: Order queue for fulfilment

• Status (multi-select dropdown) — Pending / Picking / Packed / Shipped. Default: Pending+Picking.
• Required-by Date (date range) — Default: today + next 7 days.
• Warehouse (dropdown) — Default: current user's primary warehouse.
• Priority (pills) — Standard / High / Urgent.

Example 3: Ticket dashboard for support

• Status (multi-select pills) — Open / In Progress / Awaiting Customer / Resolved.
• Assignee (dropdown) — Default: "My Tickets" (current user).
• Priority (pills).
• SLA Status (toggle) — On = only show breaching SLA.
• Customer Tier (multi-select) — Bronze / Silver / Gold / Platinum.

Saved filter sets

If a particular combination is used often, users can save it as a Data Layout — see the Data Layouts section. The Data Layout captures every filter setting plus the column arrangement plus the sort order, giving the user a one-click way back to their preferred view.

Permission-respecting filters

Filter dropdowns that source their options from a datastore (e.g. a Salesperson filter listing the users group) respect the same permission rules as the rest of the platform. A user without read access to the Salespeople table sees no options in the filter — which is correct, but worth knowing when debugging "why doesn't this filter have any options for this user?".

Row Actions are the buttons that appear next to each row in a Browse View — typically Edit, View, Delete, plus any custom actions you add. They're the primary way users interact with individual records on a list page.

Standard row actions

Every datastore-backed Browse View can show some or all of these standard actions automatically. Their visibility per row depends on the user's permissions on the underlying datastore:

• View — opens the row's read-only detail page. Always safe to expose to users with Read permission.
• Edit — opens the auto-generated edit form, pre-populated. Requires Edit permission.
• Copy — duplicates the row into a new draft. Requires Write permission.
• Delete — soft-deletes the row. Requires Delete permission.
• Audit History — shows every change to this row over time (if audit mode is on). Requires Read permission.

Custom row actions

Beyond the standards, add any number of bespoke actions per Browse View. For each you configure:

• Button label and icon (Font Awesome class).
• Style — primary / secondary / danger / success colour variants.
• What clicking it does — one of four destination types (covered below).
• Conditional visibility — only show the button on certain rows based on field values.
• Per-role permission — which security groups can see this action.
• Confirmation dialog — optional "are you sure?" prompt before the action fires.

The four destination types for custom actions

1. Open a URL

The simplest. Clicking the button takes the user to a URL, with merge tokens substituted from the row data. Common patterns:

• /page/orderdetails/##AMDATA_id## — deep-link to a custom page.
• mailto:##AMDATA_email## — open the user's email client.
• https://external-system.com/lookup?ref=##AMDATA_refnumber## — open an external lookup.

2. Call a Javascript function

For client-side interactivity that doesn't need a page load. The button calls a function in your platform's loaded JS with the row data passed as an argument. Useful for opening modals, copying values to clipboard, triggering animations.

3. Run a Custom Form

Opens a pre-configured Custom Form pre-populated with the row's data. The form acts on the row when submitted. Examples:

• A "Quick Update" form that lets the user change just one or two fields without opening the full edit dialog.
• A "Send Notification" form that prompts for a subject and body, then emails the customer.
• A "Log Call" form that creates a child record (a call-log entry) linked to the customer.

4. Trigger an AJAX endpoint

Calls a configured endpoint in the background (no page load) with the row ID as a parameter. The endpoint does whatever you need — typically a state change on the row, like marking a ticket resolved or shipping an order.

Conditional visibility

Most row actions shouldn't appear on every row. The conditional-visibility rule lets you restrict where the button shows up. Three common patterns:

• State-based — "Mark as Shipped" only appears on rows where status = "Packed".
• Permission-based — "Cancel" only appears for users in the Customer Service group.
• Computed — "Resend Invoice" only appears when invoice_sent_date IS NOT NULL.

Three real-world action sets

Example 1: Order management

• View — always visible.
• Edit — only when status is not Shipped or Cancelled.
• Mark as Shipped — only when status is Packed.
• Generate Invoice — only when status is Shipped and invoice not yet generated.
• Cancel — only when status is Pending.
• Refund — only when status is Shipped or Delivered, and only for Finance team.

Example 2: Ticket queue

• View — always.
• Take (assign to me) — only when ticket is unassigned.
• Resolve — only when status is In Progress and assigned to current user.
• Escalate — always for support team.

Example 3: Customer profile

• View — always.
• Edit — for customer success team only.
• Send Welcome Email — only for new customers (less than 30 days old).
• Schedule Call — opens a booking calendar pre-filled with the customer.
• Open Support Tickets — links to the tickets browse view filtered to this customer.

Tip: Don't expose too many actions per row. More than 4-5 buttons becomes overwhelming. Group secondary actions into a dropdown menu ("more actions") to keep the primary row clean.