Filtering Airtable Records by the Logged-In External Approver

Airtable has no native way to filter what a non-licensed user sees based on their identity. That gap becomes a real problem the moment you need external people, contractors, clients, approvers, to interact with only the records that belong to them.

Why Airtable's sharing model falls short here

Airtable's "current user" filter in interfaces only resolves to a licensed seat holder. If someone accesses a form or interface without a paid seat, Airtable has no concept of who they are at the record level. It cannot say "show only the rows where the Approver field matches the person viewing this page."

Even in enterprise setups where everyone authenticates against a company domain, authentication and licensing are separate things. A viewer who can open a form is not the same as a user Airtable can filter on. The platform was not designed to serve row-level, identity-aware views to unlicensed visitors.

The workarounds people try

The most common approach is building a separate layer outside Airtable entirely. People write a small server-side app that reads from the Airtable API, checks the logged-in user's email against a field in the base, and returns only the matching rows. This works, but it means maintaining authentication logic, API tokens, and a deployment just to show someone two records.

Another pattern is sending each approver a unique pre-filled form URL with a hidden field that identifies them. This avoids the login problem but creates a new one: links can be forwarded, there is no real access control, and generating unique URLs for every approver on every project gets tedious fast.

Both approaches solve the immediate problem while creating ongoing maintenance work.

How CollabPortals handles this

CollabPortals connects directly to an Airtable base via OAuth and publishes a portal on a shareable URL. Visitors log in with an email-plus-code flow, no Airtable seat required. Because CollabPortals knows who is logged in, it can filter the records shown to each visitor based on their email address matching a field in the table.

For an approvals workflow, you would set up a portal that surfaces the projects table, then configure row-level filtering so each visitor only sees rows where their email appears in the Approver field. Tom logs in, sees Project ABC, reviews the data, and submits his response. He never sees projects assigned to someone else.

Field-level and table-level permissions let you control exactly what each visitor can read versus edit. You can expose the project details as read-only and make the approval status field editable, nothing else. Pricing is a flat $10 per month for unlimited portals and unlimited visitors, so adding fifty approvers costs nothing extra. See client portal use cases and internal request portals for more on this pattern.

When it is not the right fit

If your approvers are already licensed Airtable users and you want the approval workflow to live entirely inside Airtable interfaces, a dedicated tool is unnecessary overhead. Similarly, if the filtering logic is highly conditional, involving complex multi-table joins or scripting, a custom-built app gives you more control than any portal layer will.