Interface Designer permissions

Last updated: November 2, 2026

Plan availability	All plan types
Permissions	Interfaces are available to all customers on all plans, however, the ability to share interfaces separately from the base is restricted to paid plan users only. Unlike share views, interfaces can only be shared with users that have a verified Airtable account. Additionally, Business or Enterprise Scale organizations with SSO enabled must provision users for them to be able to access interfaces associated with their organization's instance.
Platform(s)	Web/Browser, Mac app, and Windows app
Related reading	Interface Designer: Your guide to designing an interface Getting started with Airtable Interface Designer Managing and sharing interfaces
Airtable terminology	Interface-only users - Users who are only invited to the interface, not the underlying base. This is a paid plan-only feature.

Interface Designer at a glance

Because Interface Designer offers flexible ways to simplify workflows, visualize data, and tailor information to different audiences across organizations, it's important to review the permissions assigned to any/all interfaces, bases, and data you share with collaborators. Read along to learn the ins and outs of permissions in Interface Designer.

Interface Designer is a powerful way for creators to work and partner with collaborators who don't need full access to all the information stored in an underlying source base. Instead, creators can build interfaces on top of the source base—ensuring collaborators always see and interact with the information most relevant to them. Consult our Getting started with Interface Designer article if you are interested in learning more about why and when to use Interface Designer.

Interface Designer permissions overview

The information in this article is specific to Interface Designer. Check out our Airtable permissions overview article for details about additional permissions in Airtable.

After publishing an interface, creators can share it with other users. This allows creators to define their permission level/type and restrict access to certain data.

Users can share interfaces with individuals or groups* (Business and Enterprise Scale only) directly via email, with the option to notify users.
Additionally, base creators can create one or more invite links that automatically grant interface access once clicked. Invite by link is only available to base creators when workspace restrictions permit doing so. These options are covered in more detail in this support article.
In cases where you might need to grant access to external colleagues, consider adding the Portals feature.

The following chart helps visualize how Interface Designer permissions impact different levels of collaborators:

Interface Designer actions	Interface-only viewer (Internal or Portal non-members access)	Interface - only commenter (Internal or Portal non-members access)	Interface - only editor (Internal or Portal non-members access)	Base viewer	Base commenter	Base editor	Base creator	Non-Airtable user / external colleague (Without Portals access)
Can view interfaces	✅	✅	✅	✅	✅	✅	✅	❌
Can comment on interfaces	❌	✅	✅	❌	✅	✅	✅	❌
Can edit interface records	❌	❌	✅	❌	❌	✅	✅	❌
Create / delete new records in interfaces (When enabled)	❌	❌	✅	❌	❌	✅	✅	❌
Can create new records via form entry in interfaces containing form functionality	❌	❌	✅	❌	❌	✅	✅	❌
Can access the full base	❌	❌	❌	✅	✅	✅	✅	❌
Can add or update interfaces and interface pages	❌	❌	❌	❌	❌	❌	✅	❌
Can share access to interfaces at their permission level	⚠ ¹	⚠ ¹	⚠ ¹	✅	✅	✅	✅	❌
Billable (Team or self -serve Business plans)	❌ ²	✅ ²	✅ ²	❌	✅	✅	✅	❌

¹ When interface access restrictions are enabled, users with interface-only access are not able to share interfaces with other users. You can learn more about this feature below. Additionally, Portal non-members may not share access with others at any time.

² Review the Portals article for more information about when portal non-members could become members and then be considered billable.

Using Interface designer permissions

Before sharing an interface with a collaborator or group, we suggest using the “Preview” or “View as” features for testing purposes. Testing the sharing flow ensures the intended collaborator has access to—or is limited to—the information you shared with them.

As part of interface building, thinking about permissions allows you more control and flexibility over your and your team’s work. So, once you’ve opened or started creating an interface, consider who you’re sharing your work with—what access their contribution requires—and the sensitivity of the data being shared.

Permissions for viewing records in interface:

You’ll be able to personalize interface content for users via the "Filters" section. Then, find the "Filter by" option. Here you can set whether:

All records - All users see all records possible based on other interface settings.
Specific records - All users see only specific records based on one or more conditions or conditional groups.
Viewer’s records - Users only see only their records. A user field is required for this option to be available. Additionally, Business or Enterprise Scale users have access to user groups functionality allowing them to give viewing access to the same records for an entire group of users. To configure this setting, click the cogwheel next to the "Filter by" option. Then create a condition "Where" the {user field of your choice} > "is" > "Current user." Choose "Current user" from the dropdown.

Permissions for editing or adding records in interfaces

When creating or editing an interface page, click on the visualization on the canvas, such as a "List" or "Grid". Then, under the "User actions" section on the properties panel on the right, you'll be able to allow users with the appropriate permissions to:

Edit records inline - This will allow end users to edit records in a similar fashion to the way that record editing and adding work in a base. This will allow users to update the record without clicking into the record details.
- Add/delete records inline - This option allows end users to add records directly to the table. This setting may only be enabled if the "Edit records inline" settings is on.
Click into record details - This setting allows end users to expand a record to see more details. You can choose to show the details as a Sidesheet or a Full-screen. Once enabled, creators can design record detail pages showing specific fields — in any orientation to their end users. Additionally, individual fields can be set to be “View-only” or “Editable.”

You can choose to enable just one or both of these options can be enabled at the same time, depending on your workflow's needs.

From the properties panel for an interface page, you will also find the option to allow end users to toggle the “Add records through a form” option. This will create an "Add record" button that can be configured further.

Interface designer permissions dependencies

With Interface Designer, certain parts of Airtable and how permissions interact with collaborators have changed in ways that impact how creators/collaborators previously used Airtable. Please review and consider the following updates to Airtable when creating interfaces and sharing them:

Field visibility - Interface Designer replaces the need for hidden fields because now collaborators only see fields and information you've shared with them specifically.
Filter elements - In addition to showing a filtered set of records to all users, interface creators can choose to enable custom filters that will allow users to filter data based on any of the visible fields in the view. They can also opt to set filter elements (tab and dropdowns) that filter data for end users based on specific fields. These end-user sort, filter, and group selections are personal and session-based — when one collaborator changes them, it only changes what that collaborator sees. It doesn't change the creator's underlying interface configuration or what any other collaborator sees.
Viewing individual records details: When expanding a record to see its details, you can choose to show the details as a Sidesheet or a Full-screen. Once enabled, creators can design record detail pages showing specific fields — in any orientation to their end users.
- Collaborators only see fields that creators add to their record detail pages. As a result, hidden fields are no longer available.
- Detail pages are reusable per table and per interface.
- So, for example, if a creator has two grids on two separate detail pages in an interface showing records from their “projects” table, they’ll have the option to use the same record detail page layout if desired.
Disappearing records - If a collaborator’s access is revoked, they will immediately lose access to the interface they’re using. But if the collaborator updates an interface, causing the record not to match filters, then end users will retain access to that record for 5 minutes.
Workspace restrictions - For Team plans, workspace sharing restrictions are extended to interfaces (but not domain restrictions). Business and Enterprise Scale plan restrictions impact both workspace sharing and domain restrictions.
Inherited access - Access to a base grants access to every interface built on that base, and workspace-level permissions are inherited by every base and interface in the workspace. Restricting someone to a subset of interfaces means removing their base and workspace access first, then re-inviting them as an interface-only collaborator. See Limiting a base collaborator to specific interfaces.
Comment routing: If you receive a notification for being @mentioned in a comment and click on the link to the record, you will be taken to where the comment was made (whether that was made on an interface or the underlying base). If you do not have access to the surface where the comment was made, you will be taken to the base or interface where the record is visible where you were last active.
Interface-only impact on billing: Granting interface-only permissions to users can impact the workspace owner's billing. To learn more about how billing works, review Airtable's billing overview.
Select field options - An interface-only editor can add new options to a single select or multiple select field from within an interface, even without base-level access, when the field is editable inline and the element is set to allow adding new options. If either setting is off, the editor can only pick from existing options. This is different from bases, where only Owners and Creators can add new select options.

Understanding why filters are not access control

Filters decide which records appear on a page. They don't decide who can open the page. If you need a smaller audience to see less, build a separate interface—don't rely on a filter.

A view filter in the underlying base is a convenience, not a permission. Anyone with base access can open any view and see every record in it.
A page-level Filter by setting controls which records the page shows, but anyone who can open the page can reach the page.
Sharing granularity stops at the interface and the interface page. There's no per-collaborator permission inside a single page.
Anyone with access to the base, including the data layer, automatically has access to every interface built on that base. To stop someone seeing an interface, remove or downgrade their workspace access first, then remove their data layer access, then invite them back at the interface level only.
Workspace-level collaborator permissions act as a floor. A collaborator's workspace permission is inherited by every base and every interface in that workspace, so you can't reduce someone's access below it from inside an interface.

Current-user filtering is the exception—it does restrict what an individual signed-in viewer can see. See the "Filtering data by current user" section below.

Filtering data by current user

Interface page layouts allow you to set a filter that will conditionally filter records to only show records where the current logged-in user (or member of a user group) has been added to a user field. This is helpful for interface permissions in two ways:

It locks down data in records to only be shown to individual users or users belonging to a user group who have been added to a user field. For example, this means that interface-only commenters would access an interface and only see records where they have been added to the user field. This can help prevent end users from seeing sensitive data.
It gives end users a more relevant and simple experience with the overall data set held in an Airtable app. For example, let’s say that you have a user field to track who is responsible for completing tasks in a “Projects” base. By adding a user field filter to an interface page, logged-in end users will only see tasks that they are responsible for completing.

To set up up a dynamic “Current user” filter:

Navigate to your home screen and open the base of your choice.
Click the Interfaces tab in the upper portion of the screen.
Navigate to the interface page that you want to filter by the current user.
1. Note that the table that the interface page is referencing will need to contain a user field type to leverage this functionality.
Click on the canvas near the title of the interface page. This will open the interface page properties, not to be confused with the individual properties panel that is shown when clicking below this area on the canvas.
Under the “Data” group click the cog icon next to the “Filter by” setting.
Click + Add condition.
Next to “Where” select the user field that you want to leverage for the filter you are setting up.
Click the Select a user dropdown. Then, select the Current user option.
1. Note that changing the operator will result in different behavior which is covered in the “Notes and limitations” section below.
You can click the X to close out the filter modal. Be sure to Publish the interface so that end users will experience the updated filtering functionality.

Notes and limitations:

This functionality can only be accomplished at the interface page level. Different pages in the same interface (and different interfaces and their pages) will not inherently reflect this change. You’ll need to set this up for each page.
Publicly shared interface pages can potentially expose data and/or completely limit the data available when the “Current user” filtering feature is enabled.
If a user group is added to a record’s user field and that user group includes the current user, then they will have records shown or filtered based on their inclusion in that group.
When utilizing the dynamic “Current user” option, it’s very important to think about the expected behavior of the different operators that can be used in a filter statement. Those different operators will result in different records being shown or filtered for the logged-in end user. Additionally, when the “Allow adding multiple users” toggle is enabled in a user field there will be different operators shown:
- Single user field
  - Is - Will only show records to the current user when their name has been added to the user field.
  - Is not - Will only show records that don’t contain the current user’s name (or a user group containing the user) in the user field.
  - Is any of - Will show records to the current user when their name has been added to a field, However, if other user specific user names or user groups have been added to the filter statement, then the interface page will also show records where those users have been added in the user field.
  - Is none of - Will only show records to the current user when their name and the names of any other users (or user groups) added to the filter statement are not present in the user field.
- Multi user field
  - Has any of - Will show any records to the current user where their name has been added to the user field.
  - Has all of - Will only show records to the current user where their name and any other user (or user group) added matches the user conditions set in the filter statement.
  - Is exactly - Same behavior as the “Has all of” setting above.
  - Has none of - Will only show records to the current user when their name is not present in the user field and no other user (or user group) in the filtering statement has been added to the user field.

Filtering by current user when your records don't use a user field

The procedure above depends on a user field, which links each record to an Airtable collaborator. Many bases identify people another way—with a linked record to a "Team" or "Sales reps" table, or with a name imported from another system. Filtering on a linked record's name is static: it matches 1 named person, so you'd need a separate page for each person. To keep 1 shared page, put each person's email address on the records you're filtering and compare it to Current user’s email.

To filter an interface page on an email lookup:

Open your Airtable home screen.
Open the base that contains your interface.
In the table that holds your people records—for example "Sales reps"—add an email field if there isn't one, and fill in each person's Airtable account email address.
In the table you want to filter—for example "Leads"—add a lookup field that looks up the email field through the existing linked record field.
Click Interfaces at the top of the base, then open the page you want to filter.
Click the canvas near the title of the page to open the interface page properties.
Under the "Data" group, click the cog icon next to the "Filter by" setting.
Click + Add condition.
Next to "Where", select the email lookup field.
Open the value dropdown and select Current user’s email.
Close the filter modal, then publish the interface.

Notes:

The comparison uses the signed-in viewer's verified Airtable account email address, so the email on the record has to match the address they sign in with.
This still isn't access control. It changes which records the page shows, not who can open the page. See "Understanding why filters are not access control" above.
As with user field filtering, this is set per page. Repeat it on every page that needs it.

Nested record page depth for interface-only collaborators

Interface-only collaborators, including those using an interface as a portal, can open a maximum of 3 levels of nested record pages. When a navigation path requires a 4th level, the record page doesn't open for them and they see a message saying the record is hidden.

Base collaborators aren't subject to this limit, so a path that works for you as a Creator can still fail for an interface-only collaborator. Test deep navigation paths while signed in as an interface-only collaborator.

The 3-level depth limit is a hard limit that is set by Airtable and isn't configurable from Interface Designer or admin panel. To resolve the error, shorten the navigation path rather than trying to raise the limit.

To shorten the path, you can:

Link directly to the destination record page from an earlier page instead of stepping through every intermediate page.
Combine 2 intermediate pages into 1.
Filter data by current user on a top-level page so collaborators reach their records in fewer steps.

FAQs

How do I upgrade and downgrade interface collaborator permissions?

Check out our Billable collaborators article to learn how to upgrade and downgrade interface collaborator permissions

Can I share an interface with anyone as a view-only link or do they have to have an Airtable account?

There are other related considerations outlined in the FAQs below, however, an Airtable account login is the first requirement in order to view an interface. To share information from a base with people who do not have an Airtable account consider creating a base or view share link.

Who can create new interfaces/interface pages?

Users with Owner or Creator collaborator permissions on a base can create new interfaces and interface pages.

Can I share an interface without sharing the base?

While interfaces are available to all customers on all plans, the ability to share interfaces separately from the base is restricted to paid plans only. Learn more in this article.

If a base collaborator has "Commenter" or "Read-only" base permissions, can they edit an interface’s "Editable" fields?

No, a base collaborator with Commenter or Read-only permissions on a base can't edit or modify a base's records through an interface. This also means that Commenters and Read-only users can't fill out a form element inside an interface — a form element is an editing surface, so it follows the collaborator's interface permission level.

This limit applies to form elements inside the interface. It doesn't apply to a link that sends someone out to a separate form view, which applies its own permissions — so a Commenter or Read-only collaborator can open a shared form view and submit it.
To send someone to a form that already has values from the record they were looking at, see Prefilling a form via encoded URL.

How do field and table permissions impact interfaces?

Field and table permissions set in the base will extend and be respected in interfaces as well.

Can I see what interfaces a user has access to?

Business and Enterprise Scale admins can navigate to the Admin panel’s Users tab to view a particular user and confirm the interfaces they have access to and their permission level per interface.

Otherwise, use the interface “Share” dialog to view and manage access.

How can I see all the interfaces that exist across my organization?

Business and Enterprise Scale admins can navigate to the Admin panel’s “Interfaces” tab to see the full list of interfaces within the organization.

Why am I receiving a "You are not permitted to perform this operation" error?

Here are some common things related to permissions that could be causing the error or preventing you from taking the desired action.

Field permissions: Do users have access to edit the contents of the field in both the interface and the base?
- For example, if an interface-only editor is trying to edit a field that has field permissions set to creators and up in the base, the interface-only editor wouldn't be able to edit the field in the interface.
Table permissions: Are table permissions restricting the user from adding/deleting records?
- For example, a person navigating the interface may not see an Add Record button (even though the settings are configured to allow this) if the table permissions are set within the base to only allow certain users to add/delete records.
Primary field is a formula: Is the primary field a formula field?
- If so and the user is attempting to create a linked record and the primary field is a formula, they wouldn't be able to create the linked record if the field is set to “Pill” instead of “Card” because formulaic fields are not manually editable and the pill configuration only allows you to see/edit the primary field.
Synced tables: Is the source table synced? If so, the error may be coming from sync-related permissions.
- For example, suppose a user attempts to create a record within the interface. This action would be restricted since the source is a synced table. Manual creation or deletion of records is not allowed for synced tables.

Does the interface selector in the "Invite via link" dialog restrict the link to only that interface?

No. The interface dropdown in Share Interface > Invite via link lets you choose which interface the invite starts on, but the resulting link still grants access to every interface the invited collaborator's permission level covers — not just the one selected in the dropdown. If you need to restrict access to specific interfaces, manage permissions per interface (or per group) instead of relying on this selector.

Why don't I see the Commenter option when sharing an interface?

Commenter is only offered on the sharing paths that grant more than read-only access. Check which one you're using:

Inviting by email, inviting a user group, or creating an invite link — choose Editor, Commenter, or Read-only as you send the invite.
General access — you can set a commenter level for everyone in your organization, but General access is only available on Business and Enterprise Scale plans.
Share to web — a publicly shared interface page is read-only, so no permission level is offered at all.

Two other things narrow the list you see:

You can only grant access at your own permission level or below. If you hold Commenter access to the interface yourself, Editor won't appear as an option.
Each plan sets a maximum number of commenter collaborators. On the Free plan, once a workspace reaches that maximum, the share dialog stops accepting new commenter invites and shows a "Commenter limit reached." message.

Commenter access lets someone read records and leave comments. It doesn't let them edit records or fill out form elements in an interface.