Record Filtering
Limit which records show up in a portal table using field conditions. Combines with record ownership and role-based access.
Overview
Each table in a portal can carry an optional record filter: a list of conditions that restrict which rows end users see. It is configured in the admin UI, per table and per role, and it is a separate mechanism from record ownership, which scopes a table to the records the signed-in user owns.
Use record filtering when you want a portal (or a role within a portal) to see a subset of a table, not the whole thing.
When to Use It
| Scenario | Record filter | Record ownership |
|---|---|---|
| Show only "Active" projects in the portal | Yes | No |
| Show each user only their own records | No | Yes |
| Hide draft records from external users | Yes | No |
| Restrict read access to a single status value | Yes | No |
The two compose: a table can have both a record filter and owner scoping. Both are applied to the same fetch, so a user sees the rows that match your conditions and belong to them.
Record filtering is central to multi-location setups. See inventory management portals and retail operations portals for worked examples.
Configuring a Record Filter
- 1
Open the table's Access tab
In the portal admin, open the role you want to configure, open the table you want to filter, and stay on the Access tab. The "Record Filter" section sits under the table's permissions and its record visibility.
A filter belongs to the table, so it applies to every page built on that table. If the table has more than one page, set it on the main one: the Access tab on any other page shows a link to the main page instead of the controls.
- 2
Add a condition
Press Add condition. A condition is a field, an operator, and usually a value. Add as many as you need, and remove one with the x at the end of its row.
- 3
Pick a field and an operator
Choose which field the condition runs against. Every field on the table is offered, whatever its permissions, apart from button fields, which hold an action rather than a value Airtable can be queried on. Filtering on a field your end users cannot see is a normal thing to do: the condition runs on the server and the field itself stays hidden. The operators offered depend on the field type (see the table below), and "Equals" is the default when it is available.
- 4
Enter a value
A value is either something you type or the signed-in user's own data. For single-select fields you pick from the defined options, for checkboxes you pick "Checked" or "Unchecked", and for text, number and date fields you type it in. Operators like "Is empty" and "Is not empty" take no value at all.
Instead of a literal you can point the condition at the signed-in user, or at a field on their own record, so "Region is the viewer's own region" is one condition rather than one filter per person.
- 5
Choose how the conditions combine
With more than one condition, the dropdown above them decides whether a row has to match all (AND) of them or any (OR). One conjunction covers the whole list.
Filters save with the rest of the portal settings and take effect on the next table load for end users.
Supported Operators by Field Type
The operators offered depend on the field type:
| Field type | Operators |
|---|---|
| Single line text, multiline text, email, URL, phone | Equals, Does not equal, Is empty, Is not empty, Contains |
| Number, percent, currency, rating | Equals, Does not equal, Is empty, Is not empty |
| Single select | Equals, Does not equal, Is empty, Is not empty |
| Multiple selects, linked records, lookups | Is empty, Is not empty, Contains |
| Checkbox | Equals (Checked or Unchecked) |
| Date, date and time | Is empty, Is not empty |
| Formula, rollup | Equals, Does not equal, Is empty, Is not empty, Contains |
Date equality and range filtering are not supported in the record filter. If portal users need to narrow by date themselves, the filter controls can filter a date field by month. For a fixed condition, filter a companion field (like a single-select "Status") instead, or raise it on the public roadmap.
If you have not defined any roles, the portal uses a single default role, and the record filter you configure applies to every end user. Adding roles later lets you give each role its own filter.
Removing a Filter
Remove a single condition with the x at the end of its row. Remove them all and the filter is gone, so the table shows every record the role can otherwise see on the next load. There is no separate "off" switch.
Interaction with Other Features
- Role-based access. Each role has its own record filter. An "Admin" role can see every record while a "Viewer" role can be locked to a subset of the same table.
- Record ownership. Applied to the same fetch as the filter. On a table set to "Only their own records", end users see the rows that match your conditions AND belong to them. On a table set to "Everyone (all records)", the filter is the only thing narrowing the list.
- Table permissions. If the table has View turned off, the filter is irrelevant. Filters only narrow what is already visible.
- Page filters. A page can narrow what it lists further with its own page filter. It works on top of this filter and can never show more than it allows.
- Deleted fields. If you delete a field in Airtable that a condition uses, that condition matches nothing until you change it. With all of the conditions, portal users with this role see none of the table's records and cannot open any of them; with any, the other conditions still apply. A filter never shows more records because a field went away.
Next Steps
- Record Ownership - Show each user only the records they own, including through a lookup
- Table Permissions - Enable or disable table-level actions
- Linked Record Filtering - Restrict a linked record picker to records you choose
- Role-Based Access Control - Different filters per role
- Filter & Sort Controls - Let users filter, search and sort within what they can see