CollabPortals
Feature

Table Permissions: View, Create, Edit and Delete

Decide per table and per role whether portal users can view it, add to it, change it, or delete from it. Four independent switches, nothing implied.

Start free Setup guide

Not every table in a base belongs in a portal. Most bases have a few tables the outside world should see and a few that exist for your team: pricing workings, internal notes, the CRM pipeline.

Table permissions are the first cut. They decide which tables exist at all for a given role, and what that role may do inside them.

What it does

Every table you share has four independent switches, set per role (the user table is the exception, and has none):

  • View: whether the table appears in the portal at all
  • Create: whether the role can add records to it
  • Edit: whether the role can change existing records
  • Delete: whether the role can remove records

View off means the table is gone. Not read-only, not empty: absent from the navigation and unreachable. Create, Edit and Delete each require View, because there is nothing to act on in a table the role cannot see.

Why it matters

This is the switch that lets one base serve people who should never meet most of it. A client sees Projects and Invoices. Your team's Rate Card table is not hidden behind a permission error; as far as that client's portal is concerned, it does not exist.

It is also the layer that decides how much of a portal is a form and how much is a workspace. A table with View on and everything else off is a read-only record of what you have done. Turning Create on makes the same table a place people file requests.

How it works

Set the four switches per table on the portal's Access tab, once per role. A portal with no roles configured has one permission set, shared by everyone who logs in.

Table permissions are the coarse control, and they compose with the finer ones:

  • Field permissions decide which columns are visible or editable inside a table the role can see
  • Record filtering and record ownership decide which rows appear

Those three narrow each other, always downward. A field cannot be editable in a table the role cannot edit, and a record cannot be seen in a table the role cannot view.

The user table is the exception: it has no table-level switches. People reach their own record through the profile page, the table becomes a browsable page only if you switch Show as page on for it, and portal users can never create or delete rows in it.

Configure the most restricted role first. It is easier to open a portal up than to notice something that should have been closed.

The table permissions guide covers the interactions in detail.

Who it is for

Every portal uses these, but they matter most where one base has a clear internal side and external side: internal request portals, client portals, and inventory management where suppliers see stock but not margins.

Try it on your own base

Connect Airtable, build a portal, and share it. Seven days free, no card needed.

Start free All features

Related guides and examples

Feature

Field Permissions Down to the Single Column

Control each Airtable field separately, per role: whether it is visible, whether it appears on the create form, whether it can be edited, and whether it is required.

Feature

Roles: One Portal, A Different View for Each Person

Define roles like Admin, Editor and Viewer from a field in your user table. Each role gets a complete permission set of its own, in the same portal.

Use case

Internal Requests

Let employees submit hardware requests, IT tickets, supply orders, and internal service requests through a portal connected to your Airtable operations base.

Guide

New Feature: Rename the Words Your Airtable Portal Uses

Set what one row is called on any table and your portal rewrites itself around it, from the create button to the delete prompt to the empty state.