Browse Views

The public record catalogue — cards from your own template, filters and search, sorting including by distance, and an optional map.

Overview of Browse Views

A browse view is a public, searchable catalogue of one datastore's records, such as courses, venues, vacancies or products. Visitors filter, sort, search and page through it without signing in, and each record is drawn as a card from an HTML template you write.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — the list of views; open one in the Browse View Builder to configure it

What a browse view is, and is not

Public. No sign-in is needed, and the listing is deliberately not limited by organisation: it shows the datastore's records to anyone. Use the Filter Data card to restrict what is published.
One datastore. Each view lists records from a single datastore, shown in the Builder as the Database Table Name.
Cards, not columns. Each record is drawn from the List template under Item Appearances; there are no columns to size or headings to click.
Not an admin grid. For lists staff work with, use the datastore's own list in the administration screens.

Visitors open a browse view by its number (its ID in the Browse Views list), so link to it from your site's menus or pages.

The Browse View Builder

The Builder shows the view's name and datastore at the top, then these cards:

Field Configuration: for each field, its Filter Mode, whether it is included in search, whether it is sortable, and whether it is shown at all. See Configuring Columns.
Paging: Records Per Page, from 1 to 100 (100 by default).
Item Appearances: the List, Search and Map Pin templates, with a Placeholder Tags panel.
Filter Data: standing conditions every listing obeys, such as "Published is Yes".
Location & Distance: nearest-first sorting, a radius filter and a map. See Sorting by Distance.

Click Save Browse Layout to save. Problems are reported in a pop-up titled "Error".

Building a view

Create the view in the Browse Views list, choosing its datastore, then open it in the Builder.
In Field Configuration, tick Show in Browse View for every field the cards use, and choose which fields filter, search and sort.
Write the List template, using tags such as ##AMDATA_title##; ##AMDATA_ID## is always available for building a link to the record.
Add a Filter Data condition so only records meant for the public appear.
Set Records Per Page, save, and open the view as a visitor would.

Paging

Results are served a page at a time. Visitors see "Results:" with the total number of items across all pages, and a pager with page numbers, first and last links, and "Page X of Y". The pager is hidden when everything fits on one page. Changing a filter, the sort, the postcode or the distance returns to page 1.

What goes wrong and how to tell

A card shows a raw tag such as ##AMDATA_price##: that field is not ticked Show in Browse View. In the Placeholder Tags panel, green tags are available and red ones are not.
"Unable to find view ID": the view number is wrong or belongs to another organisation.
"Results: 0 Item(s)" and nothing else: the Filter Data conditions or the visitor's filters exclude everything. There is no empty-results message, so consider saying in the page text what to try.
The listing stops loading after a Filter Data change: a condition could not be applied. Simplify it.

Worked example

A college publishes its short courses. The view lists the Courses datastore, filtered by Filter Data to courses marked Published. Subject is a Tickbox List filter, Fee (a number field) a Range Slider, and Title is both searchable and sortable. The List template shows the title, dates and fee with a "Book" link built from ##AMDATA_ID##, and Records Per Page is 24, so the 130 courses span six pages.

Recommendations

Always set Filter Data, because the view is public.
Tick Show in Browse View only for fields the cards need; nothing else leaves the server.
Link each card to the record with ##AMDATA_ID##; there is no automatic click-through.
Keep pages to a size people can scan, typically 20 to 50.

Field Configuration and Templates

A browse view has no columns. Each record is drawn as a card from an HTML template, and the Field Configuration table decides which fields reach that template and what visitors can filter, search and sort on. This article covers both.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — open a view in the Browse View Builder for its Field Configuration and Item Appearances cards

Field Configuration

One row per field in the datastore, with these columns:

Field Name and Field Type: which field this row is about.
Filter Mode: whether visitors can filter on it, and how (see Filters and Search Boxes).
Include in Search: whether the search box looks in this field. Offered for text fields only.
Sortable: whether it appears in the Sort By list. Offered for text, number and slider fields.
Show in Browse View: whether its value is sent to the page at all. It must be ticked for any field used in the List, Search or Map Pin template.

Field types that cannot be filtered, searched or sorted show "Not Available" in those columns. System fields such as the record's tenant are not listed.

Item Appearances

Three HTML templates, edited in code editors:

List: one card per record in the listing.
Search: one entry per result in the drop-down under the search box.
Map Pin: the card shown when a map pin is clicked. Empty means the List template is used.

Write a value into a template with a tag: ##AMDATA_, the field's row name, then ##, for example ##AMDATA_title##. The Placeholder Tags panel lists every tag: green tags are ready to use, red ones belong to fields not ticked Show in Browse View. ##AMDATA_ID## is always available. With location switched on, distance tags such as ##AMDATA_AMdistancetext## are added.

Writing a good List template

Tick Show in Browse View for each field you need, and save.
Start from a simple card: a heading for the title, one or two supporting lines, and a link.
Cards sit inside a responsive grid row, so use column classes in your outer element to lay them out, for example three across on a desktop and one on a phone.
Build the link to the record or a booking page from ##AMDATA_ID##. Cards do not link anywhere unless your template does.
Save and check the view with real data, including records with empty fields.

Dropdown fields show their display text, not the stored ID. Values are inserted exactly as stored, so a field holding HTML is drawn as HTML: only show fields whose content you trust.

What goes wrong and how to tell

A card shows the tag itself (##AMDATA_venue##): the field is not ticked Show in Browse View, or the row name is misspelt.
Cards stack one per line on a desktop: the template's outer element has no column class.
Clicking a card does nothing: the template has no link.
A field you want to sort on is "Not Available": dates and dropdowns cannot be sorted; use a number or text field.

Worked example

A venue-hire catalogue ticks Show in Browse View for Name, Town, Capacity and Photo. The List template is a card in a column that is a third wide on desktops, with the photo, the name in bold, "##AMDATA_town## · up to ##AMDATA_capacity## people" beneath, and a "View details" link built from ##AMDATA_ID##. Capacity is Sortable, so visitors can choose "Capacity (High to Low)".

Recommendations

Send only what the cards show: unticked fields never leave the server.
Design for the empty field, so a missing value does not leave a stray label.
Keep the Search template short; it appears in a drop-down.
Use the Placeholder Tags panel rather than typing tags from memory.

Filters and Search Boxes

A browse view gives visitors three ways to narrow a catalogue: filters in a panel on the left, a search box that finds records as they type, and a Sort By list. This article covers how each is configured and how it behaves, including the limits worth knowing before you promise a particular filter.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — open a view in the Browse View Builder; filters, search and sorting are set per field in Field Configuration

Filters

Choose a Filter Mode for a field in Field Configuration. The filter panel appears only when at least one field has a filter, and each filter is headed with the field's name.

Tickbox List: a checkbox per value. Offered for text, dropdown, pills and radio fields, and for numbers. For a dropdown, only the options actually used by records are listed, by name; for pills, the pill titles in use.
Range Slider: a slider between the lowest and highest values present, with a "min - max" readout. Use it on number and slider fields.
Toggle Switch: offered for tickbox and toggle fields, but at present it draws only its heading, with no control. Do not use it; a Tickbox List on the same field is not offered either, so leave yes/no fields unfiltered or convert them to pills.

Ticking several boxes in one filter shows records matching any of them; filters on different fields must all match. A filter with nothing ticked has no effect. There is no "clear all" button: visitors untick boxes or reload the page.

The search box

Tick Include in Search for the text fields to search.
Write the Search template under Item Appearances: one short line per result.
Visitors type in the box above the listing; results drop down beneath it after a brief pause, best match first. Each word is matched from its start, so "lond" finds "London".

Search works separately from the listing: it ignores the filters and sort, and its results drop down rather than replacing the cards. When nothing matches it shows "Sorry we could not find any results." Searching needs a full-text index on each searched field, which the hosting administrator creates; without one, search fails with a configuration error.

Sort By

Each Sortable field adds two choices: "(A-Z)" and "(Z-A)" for text, or "(Low to High)" and "(High to Low)" for numbers. With location switched on, Nearest First is added. The first choice in the list is the default order, and there is no blank option.

Standing filters

The Filter Data card holds conditions every listing obeys whatever the visitor chooses, such as "Published is Yes" or "Status is Open". Visitors cannot see or remove them.

What goes wrong and how to tell

"Invalid filter information submitted" after ticking a box: a Tickbox List on a free-text field whose values are words rather than numbers. Use a dropdown or pills field for anything visitors filter on.
"The search facility for this page has not been configured yet, please contact the website owner.": no field is ticked Include in Search.
Search shows an error: the searched fields have no full-text index. Ask the hosting administrator.
A Toggle Switch filter shows only a heading: see above.
A slider will not reach a value: the slider spans only values present in the records, in whole numbers.

Worked example

A training catalogue filters on Subject (a dropdown, Tickbox List) and Level (pills, Tickbox List), with a Range Slider on Duration in hours. Title and Summary are included in search, and Title and Price are sortable, so Sort By offers "Title (A-Z)" first. A visitor ticks Health and Safety and First Aid under Subject and Beginner under Level, and sees beginner courses in either subject.

Recommendations

Filter on dropdowns and pills, not free text.
Check which choice heads the Sort By list, because it is the default order.
Keep search to the few fields people actually type, such as titles.
Use Filter Data for what must never be published, not a visitor filter.

Row Actions

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.

Sorting by Distance

A browse view can offer Nearest First in its Sort By list. The visitor types a postcode or shares their location, and the listing reorders around them, with each record's distance available to show on its card.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — open a view in the Browse View Builder and use its Location & Distance card

Architect Panel → Integration & Connections:

Postcode Lookup — the postcode positions distances are worked out from

Where a record's location comes from

In the Location & Distance card, Postcode Field lists every field that can hold a location, grouped under "On this datastore" and "Linked through" a dropdown field. Three kinds qualify:

A text field holding a postcode. Its position comes from postcode lookup.
A Postal Address field. If the address was captured with address autocomplete, its saved coordinates are used; otherwise its postcode is looked up.
A Geolocation field storing coordinates, used directly with no lookup. One configured to store an address is marked with a warning.

"Linked through" reads the location from the record a Dropdown (DB) or searchable dropdown points at, such as a placement's employer site. Only one hop is supported.

Setting it up

Open the view in the Browse View Builder and find Location & Distance.
Choose the Postcode Field.
Tick Offer Nearest First. Without it, nothing else in the card takes effect.
Tick Show Distances In Km for kilometres; leave it unticked for miles.
Click Save Browse Layout.
If the field holds postcodes, click Warm postcode cache (under Postcode Cache) and repeat until it reports the cache is complete for this view. Save first.
Add ##AMDATA_AMdistancetext## to the List template under Item Appearances to show the distance on each card. The distance tags appear in the Placeholder Tags panel once Offer Nearest First is on.

What the visitor sees

They choose Nearest First in Sort By. A row labelled Your postcode appears, with a Use my location button.
They type a postcode or use their location. The view reorders and shows "Showing distances from" the postcode or "Your location".
A postcode that resolved is remembered in their browser for next time.

Distances are straight-line, rounded to one decimal place. Records with no position are still listed, at the end, with no distance. Until the visitor gives a starting point, Nearest First leaves the order unchanged.

What goes wrong and how to tell

"We could not find that postcode. Please check it and try again.": the visitor's postcode is not known. If postcode lookup is switched off, only postcodes already in the cache are recognised.
"We could not get your location. Please type your postcode instead.": the browser refused or failed to share a location.
Many records sort last: their postcodes are not cached yet, could not be found, or contain stray punctuation. Warm the cache and check the not-found list on Postcode Lookup.
"This view has no postcode field configured yet. Choose one and save first." when warming: save the card with Offer Nearest First ticked.
"This view reads coordinates straight from a Geolocation field, so there is nothing to look up.": no warming is needed.

Worked example

A work-experience catalogue lists placements, each linked to an employer site holding a postcode. The architect sets Postcode Field to the site's postcode, linked through the placement's Site dropdown, ticks Offer Nearest First, saves, and warms the cache in two runs. They add "##AMDATA_AMdistancetext## away" to the List template. A student types their postcode, picks Nearest First, and sees "2.4 miles away" on the closest placement.

Recommendations

Prefer coordinates where you have them: they need no lookup.
Warm the cache before launch.
Show the distance on the card, so the order makes sense to visitors.
Say the distances are straight-line in the view's introduction.

The Radius Filter

Alongside Nearest First, a browse view can offer a Distance filter: "within 5 miles", "within 10 miles" and so on. It narrows the listing to records within the chosen distance of the visitor's postcode or location.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — the Browse View Builder's Location & Distance card, Within Filter Steps

Architect Panel → Integration & Connections:

Postcode Lookup — the postcode positions the distances are measured from

Setting it up

Set up the view's location first: choose the Postcode Field and tick Offer Nearest First. The radius filter does nothing without it. See Sorting by Distance.
In Within Filter Steps, enter the distances to offer as a comma-separated list, for example 1,3,5,10,25,50. Blanks and anything that is not a number are dropped, duplicates removed and the rest sorted.
The steps use the view's unit: miles, or kilometres if Show Distances In Km is ticked.
Click Save Browse Layout.

Leave Within Filter Steps blank and no distance filter is offered.

What the visitor sees

A Distance filter with "Any distance" and one option per step, such as "Within 5 miles".
Because the filter needs a starting point, a view with steps always shows the Your postcode row, and the Distance filter is disabled with "Enter your postcode to filter by distance." until a postcode or location has been resolved.
Choosing a step returns the listing to page 1 and keeps only records within that distance.

Records with no position

A record whose location is unknown (no postcode, a postcode that could not be found, or one not yet looked up) is excluded while a distance is chosen, because there is no way to say it is within five miles. It reappears with "Any distance". This is the opposite of Nearest First, which keeps such records at the end of the list.

Choosing the steps

Match them to how your records are spread: a city directory wants 1, 2 and 5; a regional one 10, 25 and 50.
Five or six steps are plenty.
Make the smallest step useful: a first choice that returns nothing makes the filter look broken.

Only the steps you configured are accepted; a distance typed into the page address that is not one of them is ignored.

What goes wrong and how to tell

No Distance filter appears: Within Filter Steps is blank, or Offer Nearest First is not ticked.
The filter is greyed out: the visitor has not given a postcode or location yet.
Records you expected are missing within a distance: they have no known position. Warm the postcode cache and check Postcodes That Could Not Be Found on the Postcode Lookup screen.

Worked example

A county's activities directory sets Within Filter Steps to 2,5,10,20 in miles. A parent enters their postcode, chooses Nearest First and "Within 5 miles", and sees the 14 closest activities in order of distance. Two clubs with no postcode recorded do not appear until the parent switches back to "Any distance"; the team adds their postcodes the next day.

Recommendations

Fill in every record's location before offering a radius filter.
Warm the cache so new records are placed.
Pair the filter with Nearest First so the nearest results lead.
Review the steps after launch against where records really are.

The Map View

A browse view with a location can offer a Map alongside its list, showing the current page of results as pins around the visitor's starting point. Each pin opens a small card you design.

Where to find it

Architect Panel → Layout & Pages:

Browse Views — the Browse View Builder's Location & Distance card and the Map Pin item appearance

Architect Panel → Integration & Connections:

Postcode Lookup — the positions the pins are placed at

Setting it up

Set up the view's location: choose the Postcode Field and tick Offer Nearest First. The map does not appear without it. See Sorting by Distance.
Tick Offer a Map View.
In Map Provider, enter osm for OpenStreetMap, google for Google Maps, or leave it blank to use the installation default. Any other value is saved as blank.
Under Item Appearances, write the Map Pin template: the card shown when a pin is clicked. It uses the same placeholder tags as the List template, and if left empty the List template is used.
Click Save Browse Layout.

The two providers

OpenStreetMap needs no key and is the default when nothing is chosen. Tiles carry the credit "© OpenStreetMap contributors".
Google Maps needs a Google Maps key in the site configuration file, which the hosting administrator sets. It is the same key used for address autocomplete.

The installation default is the Map provider setting in Site Settings, Page Builder group; blank there means OpenStreetMap. Both providers are listed in the cookie consent register under preferences, so review your cookie notice when you add a map. See Cookie Consent.

What the visitor sees

List and Map buttons above the results.
The map needs a starting point. Until the visitor enters a postcode or uses their location, the map shows no pins, so tell them to do that first.
Once a starting point is set, the map shows the current page of results, with "Showing page X of Y on the map." when there is more than one page. Moving to another page moves the pins.
Records with no position cannot be pinned, and the map says how many: "1 result has no location and cannot be shown."

What goes wrong and how to tell

No Map button: Offer a Map View or Offer Nearest First is not ticked.
An empty world map: the visitor has not given a starting point yet.
"The map could not be loaded.": the map library or provider could not be reached, or Google was chosen with no key configured. Try osm.
A pin card shows a tag such as ##AMDATA_town##: that field is not ticked Show in Browse View in Field Configuration.
Fewer pins than results: the map shows one page at a time; raise Records Per Page (up to 100) if visitors need more at once.

Worked example

A volunteering directory ticks Offer a Map View, leaves Map Provider blank (OpenStreetMap) and writes a Map Pin template with the organisation's name, ##AMDATA_AMdistancetext## and a link built from ##AMDATA_ID##. A volunteer types their postcode, switches to Map, and sees the nearest 25 opportunities pinned around them, with a note that two have no location.

Recommendations

Keep the pin card short: a name, the distance and a link.
Prompt for a postcode in the view's introduction, because the map needs one.
Use OpenStreetMap unless you need Google's mapping.
Fill in missing locations; unplaced records never appear on the map.