Configuring Columns

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: ##AMDATA_companyname## ##AMDATA_email##. 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).

Screenshot of the Columns section of a Browse View configuration showing several columns listed with their field, display name, width, searchable/sortable checkboxes, and Display Format text

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.