Record Filtering: Show Only the Rows That Apply

A table can be the right table and still hold the wrong rows. Your Jobs table has five years of history in it; the contractor logging in this morning should see the ones that are open.

Record filtering decides which rows a role is allowed near.

What it does

Per table and per role, you set conditions: a field, an operator, and a value, joined with and or or. Only records matching them appear.

A value can be a literal, or it can resolve from the person looking. " is the viewer's own region" is one condition that behaves differently for every user, with nothing hard-coded and no filter per person to maintain.

• Status is Active, so archived work never loads
• Region is North, so a regional manager sees their own patch
• Approved is checked, so drafts stay internal until someone signs them off

The available operators depend on the field type, and the filter is applied before records reach the browser. A row that fails the condition is not hidden in the interface, it is never sent.

Why it matters

Filtering is what makes a large base usable to an outsider. It is the difference between handing someone a table and handing them their work.

It is also a permission, not a convenience. Because filters are applied per role, "Viewer sees only approved records" is a rule about what that role can access, not a default someone can clear by clicking a column header.

How it composes

Filtering stacks with the other narrowing controls, and the order is always downward:

• Table permissions decide whether the role sees the table at all
• Record ownership decides whether the role sees everyone's rows or only their own
• The record filter narrows what is left to rows matching your conditions

There is a separate control for linked-record dropdowns. Linked-record filtering restricts a link field to specific records you choose, so a Project picker offers the five projects you allowlisted rather than all four hundred. It is a fixed list you set, not a per-person rule: to give each user their own options, scope the linked table with record ownership instead.

How it works

Set the conditions on the table's Access tab, per role, and check them by opening the portal as a user in that role. The record filtering guide covers the operators, and the MCP connector can add a filter from a plain-language description.

Who it is for

Portals over a base with history: issue tracking showing open tickets only, maintenance portals showing this month's jobs, and event scheduling showing upcoming rather than past events.