Using field and table editing permissions
  • 01 Mar 2024
  • 3 Minutes to read
  • Dark
    Light
  • PDF

Using field and table editing permissions

  • Dark
    Light
  • PDF

Article Summary

Plan availability

Paid plans only

Permissions

Owner/Creator

Platform(s)

Web/Browser, Mac app, and Windows app

Related reading

Changing field editing permissions

With field and table editing permissions, you can limit who can make certain changes to fields or a table. For example, you can make sure that only some coworkers can mark a project as approved, or prevent anyone from inadvertently deleting records.

Single field editing

Anyone with creator or owner permissions can limit who can change the content of specific fields in your table.

4412908139159editmultipleFieldpermissions.gif

You can click on the arrow next to a field's name to reveal a dropdown menu allowing you to edit the field permissions for that particular field:

360057152074blobid6.png

Changing table editing permissions

Paid plan users with Creator or Owner permissions on a base can limit who can create or delete records in a table.

Follow these steps to limit who can change the editing permissions on a table:

  1. Click the dropdown next to the table’s name > Edit table permissions
    360057152154blobid10.png

  2. Select who you would like to be able to create records, and who you would like to be able to delete records. You can select permission levels (Creators and up, Editors and up, Nobody), or specific users.

  3. You can also determine whether records can be created through forms.

    1. If Allow records to be created through forms is off, any forms associated with the table will stop accepting submissions.

    2. If Allow records to be created through forms is on, forms will continue to accept submissions.

        360058008553blobid11.png

End-user experience:

Users who are unable to create records will see the options to create records grayed out, with an explanation that the table is locked. Other actions that would create records will also be disabled, such as:

  • Duplicating a record

  • Inserting a record at a particular spot

  • Creating a record in other views

  • Creating a record from a linked record field

Users who are unable to delete records will see the option to delete records grayed out.

360058008573blobid12.png

FAQs

Who can change or remove the restrictions that I’ve set?

Anyone with creator or owner permissions on the base can configure or remove field/table editing permissions.

Why am I not seeing “Edit field permissions” or “Edit table permissions?”

You’ll need creator or owner permissions to the base or workspace. To confirm your permission level, click Share in the top right of the base and then click Manage. If you don’t have creator or owner permissions, you’ll need to ask someone with creator or owner permissions to grant you this access.

How can I find out which fields have had their edit permissions changed?

Paid plans can use the field manager tool to find information about all of the fields in a given table. Free plan workspace users will need to look at each field's individual editing permissions to figure this out.

How can I adjust who can see information in my base? Can I hide tables from specific users within my base?

Field/table editing permissions do not affect who can see information in the base. To share only a limited subset of information in your base, use a view share link and optionally, a form or consider adding them as interface-only collaborators.

Is it possible to lock a field’s configuration?

At the moment, field locking doesn't include locking a field's configuration (name, type, single select options).

Where do field and table editing permissions apply?

Anywhere that edits can be made - field and table editing permissions apply to our mobile apps, extensions in a base, and to edits made using the Airtable API.

Can I limit editing to just an API script or integration?

Yes, if you limit editing to the specific user whose personal access token is used by the API script or integration or, for OAuth integrations, the user who authorized the OAuth integration.


Was this article helpful?