CollabPortals

Viewing Records

How portal users view records in CollabPortals, including the data table layout, sorting, and how records are scoped to each user.

Overview

When portal users log in, they see records from the tables you've made visible, scoped by the record visibility you set on each table.

Each table can be displayed in one of five layouts: table, gallery, kanban, calendar, or FAQ. The table layout is the default and is covered here. For the other four, plus the row-vs-detail field split that applies to all of them, see View Types.

Data Table Layout

Records are displayed in a familiar table format with columns for each visible field. The table includes:

  • Column headers - Field names from your Airtable table
  • Rows - One per record
  • Pagination - Navigate through large datasets
  • Sorting - Click a column header to re-sort, from the starting order the table loads in
  • Clickable rows - Click any row to open the record detail page

If your portal has multiple visible tables, users see a sidebar or navigation bar with table names. Clicking a table name switches the view to that table's records.

A table appears in the navigation when it is enabled for the role and set to show as a page. Enabling a table is not enough on its own: one can be readable and deliberately kept out of the sidebar, reachable only through a record that links to it. See Table Permissions.

Which Records a User Sees

Each table decides this for itself, with the Who can see records setting on its Access tab:

  • Only their own records. CollabPortals identifies the user's record in the user table, then shows only the records whose ownership field points at them. This is what a table that links to your user table starts on.
  • Everyone (all records). Every user who can view the table sees every record in it. This is what a table with no path to your user table falls back to, because there is nothing to scope on.

So "each user sees only their own" is true of a table you have scoped, and not of one you have not. A reference table like Categories or Locations is meant to be in the second group. A table holding one person's private data is not, and if it has no link to your user table, it will be.

Before you turn a table on, check which mode it is in. A table with no link to your user table shows every record to every portal user, so it is worth being deliberate about the ones holding data that belongs to a specific person.

A table can reach your users through a direct link or through a lookup that follows another table's link. See Record Ownership for both, and Record Filtering to narrow a table by a field value on top of this.

Field Display

How fields appear in the table depends on their type and permission:

  • View-only fields - Displayed as plain text
  • Editable fields - Displayed as plain text in the table view (editing happens in a form)
  • Hidden fields - No column, and no row on the detail page either

Different field types have different visual treatments:

Field TypeDisplay
TextPlain text
Number / CurrencyFormatted number
Single selectColored badge
Multiple selectsMultiple colored badges
CheckboxCheck icon
DateFormatted date string
RatingStar icons
URLClickable link
EmailPlain text
AttachmentsThumbnail previews
Linked recordsRecord names as badges

See Supported Field Types for the full list.

Sorting

Users sort by clicking a column header, and the clicks cycle: ascending (A-Z, 0-9, oldest first), then descending, then back to no sort.

What that sorts depends on whether you have turned on filter and sort controls for the table:

  • With the controls on, sorting runs on the server across the whole table, and only the fields you listed as sortable have a clickable header. This still works on a table you have grouped: the sort is re-run on the server and the groups rebuilt from the result.
  • With the controls off, a header sorts the rows on the page currently loaded and no further, since the rest of the table has not been fetched. On a table that is actually grouped it does nothing at all, because grouping fixes the row order and there is no local reordering left to do. A table too large to group is not grouped, so it keeps its header sorting. See View Types for where that limit falls.

Where sorting and grouping do run together, sorting reorders rows within each group. It never reorders the groups themselves. See View Types for what fixes their order.

Columns holding a list of values (multiple select, linked records, attachments, lookups, multiple collaborators) and button columns are not offered for sorting: ordering rows by the string those values happen to coerce to would mean nothing. A single-collaborator column is fine and does sort. With the controls off that is decided per column as the table renders, so it always holds. With them on it is decided by the sortable-field list you pick from, and the MCP connector does not check field types, so a portal configured that way can end up with one of these clickable.

Admins can also set a default sort per table, so records appear in a chosen order the moment an end user opens the table. A user's own sorting replaces it for them, and never changes what anyone else loads.

How long their choice lasts depends on the same setting. With the controls on it goes into the page address alongside their filters, so it survives a reload and can be bookmarked or sent to someone. With the controls off it is held in the page only, and a reload puts the table back to your default.

Pagination

Large datasets are paginated. Users see navigation controls to move between pages. The page size is set automatically for a comfortable viewing experience.

Empty States

If a table has no records to show a user, they'll see an empty state message. If they have Create permission, they'll also see a button to create their first record.

Action Buttons

Depending on table permissions, users see action buttons:

  • New button - Appears if Create permission is enabled
  • Edit button - Appears per row if Edit permission is enabled
  • Delete button - Appears per row if Delete permission is enabled

Those are the built-in words. Every one of them can be renamed per table on its Labels tab, and setting what one row is called rewrites most of them at once, so a maintenance portal reads "Log a job" and "Delete job?" instead.

Next Steps