Roles: One Portal, A Different View for Each Person

Most portals serve more than one kind of person. A project has the client, the account manager, and the freelancer doing the work. They need the same base and very different views of it.

Roles are how one portal serves all three without becoming three portals.

What it does

A role is read from a field in your user table: a single select, a multiple select, or a linked record field. Whatever that field says for a given person is the role they get.

Each role carries its own complete permission set:

• Table permissions: which tables it can view, create, edit and delete in
• Field permissions: which columns it sees and which it can change
• View type: the same table can be a kanban board for one role and a list for another
• Record filter and record scoping: which rows it is allowed near at all
• Default sort and portal wording

Nothing is inherited by accident. A role you have not configured does not quietly get the permissions of the one next to it. The one deliberate exception is portal wording, where a label set on the default role carries to roles that have not set their own, so the normal case is writing it once.

Why it matters

The alternative is a portal per audience, which means maintaining the same permissions in several places and hoping they stay in step. One portal with roles keeps a single configuration, and lets you answer "what can a Viewer see" by looking at one screen.

There is also a default role, covering anyone whose role field is empty or holds a value you have not configured. That is what stops a new person in the user table from landing somewhere undefined.

More than one role per person

A multiple select, or a linked record field with several records linked, gives one person more than one role. They pick between them from the sidebar, which reads "Viewing as: X".

Users land on the first value in their Airtable cell, and the switcher only appears for someone holding two or more configured roles. Single-role portals are unchanged by any of this.

How it works

Point the portal at the role field, define your roles, and configure each one. The role-based access guide walks through it with screenshots, and the MCP connector can do the same setup by conversation if you would rather describe it than click it.

Who it is for

Any portal with more than one audience: sales rep portals where a manager sees the whole pipeline and a rep sees their own, client portals with an internal team behind the same URL, and issue tracking where reporters and assignees need different columns.