Skip to main content

Create a View

Goal​

Create a view — a tabular list of an entity's records — with the columns, filters, and sort order you choose.

Prerequisites​

  • You are signed in with a maker (or platform administrator) role.
  • The entity exists and has the fields you want to show and filter on.

Steps​

  1. Open the entity in Tables and go to the Views tab.
  2. Under New view, enter a display name (for example, Active Invoices).
  3. Enter a logical name. The prefix of the publisher owning the solution you are working in is shown beside the box and applied for you — invoice_active becomes par_invoice_active. This happens on standard tables too: a view you build on Account is par_account_overview, not account_overview, because unprefixed names belong to Parsware and one you invent would clash with the next view it ships.
  4. Select the columns to display by checking each field to include.
  5. Optionally add one filter (choose a field, an operator, and — unless the operator is "is empty"/"is not empty" — a value) and one sort (choose a field and whether it is descending).
  6. Leave View type on List — the entity's list page. The other types exist for other surfaces: see Create a Lookup View and Choose Which Columns a Search Matches.
  7. Optionally mark the view as the entity's default view. A view is the default for its own type, so a default list view and a default lookup view coexist.
  8. Leave Row checkboxes ticked unless this is a list nobody acts on — see below.
  9. Select Save view.
  10. The view appears in the entity's view list, with its type shown as a column.

Row checkboxes, and when to turn them off​

Rows carry a tick box by default, and the command bar acts on what is ticked: that is how Edit knows which record to open and how Delete knows which records to remove.

Turn Row checkboxes off for a view that is only ever read — a reference list, a lookup table of country codes, a log people scan and never act on. Two things follow, both deliberate:

  • The tick-box column disappears, and with it a column of width on a narrow screen.
  • Edit and Delete leave the command bar, because a view with no selection has no way to tell them which record to act on, and a button that can never be pressed is worse than one that is not there. New and Refresh stay, and clicking a row still opens the record — that gesture is unaffected.

It is a property of the view, not of the table, precisely because one table is usually both: an operational list your team works from, and a reference list they only look at. Give it two views and answer this differently in each.

The view types, and where each one is used​

A view is not only "the list page". The same table needs a different column set inside a picker than on its full list, and a different one again to decide what typing searches. Each is an ordinary view you author, rather than something the platform guesses:

TypeWhere it is usedWhat of it is read
ListThe table's list page, in an app and in the Admin Control Center.Columns, filter, sort — all of it.
LookupInside a lookup control's picker, and the Advanced Lookup grid behind the magnifier. See Create a Lookup View.Columns, filter, sort. Keep it to two to four columns: a picker is not a report.
Quick FindWhich columns a typed search matches against, in a lookup. See Choose Which Columns a Search Matches.Columns only — its filter and sort are ignored, because it answers "what does search look at", not "what is listed".
Related recordsReserved for the subgrid on a related-records tab. Nothing renders it yet, so a view of this type is stored and validated but not shown anywhere.Nothing, for now.
Quick viewA dashboard's grid widget, and anywhere else the surface already has a frame of its own — a dialog, a drawer panel.Columns, filter, sort — but drawn with no title bar and no toolbar.
CardA dashboard's card widget. Its columns are read as one record's fields, laid out as a card rather than as a row.Columns, in order — they decide which fields the card shows.

Why Quick view is its own type rather than a switch on a List view. A tile is four columns wide and a list page is twelve, and they are not the same answer. Making it a type is what lets you choose the columns for each, instead of the platform shrinking one to fit the other. It is also why a grid widget offers your Quick views first: dropping a List view into a tile puts a second header inside the one the tile already has.

If you are not sure, List is the answer: it is what every view authored before types existed is, and it is the only one an app's navigation offers.

Only List views appear in the switcher. On a table's list page, the dropdown under the title — the one that changes which view you are reading — offers your List views and nothing else. The other types are each answering a different question (a Lookup view is the inside of a picker; a Card view is one record), so switching to one from a list page would reframe the page as something it is not. They are still used, just from the surface that asks for them. This is the same rule the record page's form dropdown follows, which offers Main forms only.

What happens behind the scenes​

The view definition is saved as a canonical definition and checked against the view schema. Every field referenced by a column, filter, or sort must be a real field on the entity; a view referencing a field that does not exist is rejected.

Troubleshooting​

  • "… is not defined on this entity." — a referenced field does not exist; add it to the entity or remove it from the view.
  • "… must be lower snake-case and start with the publisher prefix." — correct the view's logical name.
  • "A form or view named … already exists on this entity." — choose a different logical name.