Table Permissions

Overview

Table permissions control what actions portal users can perform on each table in your portal. You configure these per table, and they apply to all users (or per role if you're using role-based access).

Permission Types

A table has one switch that turns it on, and three that say what can be done with it.

Enabled, in the header of the table's card, is the View permission. Off, the table is not in the portal at all. On, the role can read it.

The other three sit together under Table Access, and each needs Enabled on to mean anything:

Configuring Table Permissions

1. 1

   Open the portal

   From your admin dashboard, open the portal you want to configure, then pick the role you are configuring.

2. 2

   Open the table

   The sidebar lists your portal's pages, and every table in your Airtable base has at least one. Open a table's page and you land on its Access tab. The user table is listed too, but it has no table-level permission switches of its own (see below).

   If a table has more than one page, its permissions are set on its main page. They apply to every page of the table, so the Access tab on the others links back to the main page instead of repeating the switches.

3. 3

   Turn the table on, then pick the actions

   Switch Enabled on in the card header to let the role read the table, then use the Create, Edit and Delete toggles below it to say what they can do with it.

Showing and Hiding Tables

If a table is not Enabled, it won't appear in the portal at all. Users won't see it in the navigation or be able to reach it.

This is useful when your Airtable base has tables that are for internal use only (e.g., settings tables, lookup tables, or admin data).

When a table first appears, a table linked to your user table starts switched on, so each user sees their own records in it. Every other table starts switched off, because switching it on shows every record to everyone who can view it. See What Happens Without Links.

The dot beside each page in the admin sidebar is green when the table is Enabled (for an embed page, when the page is shown) and grey when it is not. On a portal with roles, one role is enough to turn it green. Hover over the dot to see which roles. A green dot does not by itself mean the page is in the sidebar: that is still Show as a page in the sidebar, below.

Enabling a table is not the same as giving it a page. Whether it appears in the sidebar is Show as a page in the sidebar, on the table's Display tab. A table can be enabled and deliberately kept out of the navigation, reachable only through a record it is linked to, which is how child tables like Tasks or Order Lines are usually set up.

Permission Combinations

Here are common combinations and what they enable. For real-world configurations, see how client portals, internal request portals, and project management portals mix them:

View Only

• Enabled: On | Create: Off | Edit: Off | Delete: Off
• Users can browse and search records but can't make any changes
• Good for: dashboards, reference data, reporting

View + Create

• Enabled: On | Create: On | Edit: Off | Delete: Off
• Users can see records and add new ones, but can't modify or remove existing records
• Good for: submission forms, intake processes, request tracking

View + Edit

• Enabled: On | Create: Off | Edit: On | Delete: Off
• Users can see and update records but can't add or remove them
• Good for: status updates, data collection, feedback

Full Access

• Enabled: On | Create: On | Edit: On | Delete: On
• Users have complete control over the records in the table they can see
• Good for: project management, task tracking, collaborative workflows

The User Table

The user table (the one you selected when creating the portal) is special:

• It's used for authentication, matching portal users by email
• It has no table-level permission switches. The admin panel does not show them for it
• Portal users reach their own record through the profile page, and can edit the fields your field permissions allow
• Create and delete are always refused on it, so nobody can add or remove portal users from inside the portal
• It only becomes a browsable page in the portal if you switch Show as a page in the sidebar on for it

How Table Permissions Interact with Field Permissions

Table permissions set the overall access level. Field permissions provide additional granularity within each table:

• If a table has Edit disabled, field permissions for that table are irrelevant for editing, since users can't edit anything
• If a table has Edit enabled, field permissions determine which specific fields users can edit
• A field with every switch off does not appear, regardless of table permissions, unless it is one of the four a layout is built around; see field permissions

Next Steps

• Field Permissions - Fine-tune access at the field level
• Record Ownership - Decide which records each user sees
• Record Filtering - Limit which rows a role can see
• Default Sort - Set the starting order for a table
• Role-Based Access Control - Set different permissions for different users