Contents x
    Interface Designer permissions
    • 10 May 2024
    • 9 Minutes to read
    • Print
    • Dark
      Light
    • PDF
    Contents

    Interface Designer permissions

    • Updated on 10 May 2024
    • 9 Minutes to read
    • Print
    • Dark
      Light
    • PDF
    Article summary

    Plan availability

    All plan types 

    Permissions

    Platform(s)

    Web/Browser, Mac app, and Windows app

    Related reading

    Airtable terminology

    Interface-only users - Users who are only invited to the interface, not the underlying base. This is a paid plan-only feature.

    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 at a glance

    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 

    NOTE

    The information in this article is specific to Interface Designer. To learn more about general Airtable collaborator permissions, please review this article.

    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.

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

    Interface Designer actions

    Interface-only viewer

    Interface-only commenter

    Interface-only editor

    Base viewer

    Base commenter

    Base editor

    Base creator

    Non-Airtable user / external colleague

    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

    ✅ 1

    ✅ 1

    ✅ 1

    ✅

    ✅

    ✅

    ✅

    ❌

    Billable (Team or self -serve Business plans)

    ❌

    ✅

    ✅

    ❌

    ✅

    ✅

    ✅

    ❌

    1 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.

    Using Interface designer permissions

    NOTE

    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 Add records through a form by toggling that 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.

    • 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.

    • 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: It's important to remember that 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.

    FAQs

    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 are not able to fill out form elements in interfaces.

    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.

    Was this article helpful?
    What's Next