How to Control Who Can Edit Specific Fields in Airtable

You want everyone on your team to see all the records, but only certain people should be able to edit a specific field. A common example: a status or approval field that only a manager should be able to change, while the rest of the team can view it and update other fields freely.

Airtable handles this with field-level editing permissions, available on Team, Business, and Enterprise Scale plans.

How Field-Level Permissions Work

Field permissions control who can edit the values in a specific field. When a user does not have edit permission for a field, the field appears greyed out for them. They can see the value but cannot change it.

This applies everywhere the field appears: in the base grid view, in record expansion, and in any Interface built on that base. Setting the permission once in the base covers all access points.

Importantly, field permissions control editing only. They do not hide the field from view. If you need a field to be invisible to certain users rather than just non-editable, you need to either remove it from the Interface layout for those users or give them Interface-only access without that field included. The article on why you cannot restrict sensitive data visibility in Airtable covers this distinction in depth.

Setting Field Permissions

Field permissions are set at the field level in the base, not in the Interface.

1. Open your base and navigate to the table containing the field
2. Click the arrow icon to the right of the field name in the column header
3. Click Edit field permissions
4. Under "Who can edit values in this field?", choose one of the options:

• All collaborators (default, no restriction)
• Only specific collaborators (choose from a list of users with base access)
• Only Owners and Creators
• No one (makes the field fully read-only for everyone)

After saving, any user not in the allowed group will see the field as read-only immediately, both in the base and in any Interface.

A Practical Example

Consider a cash request workflow. Team members submit requests and fill in the Amount, Description, and Date fields. A Cash Owner is the only person who should be able to change the Approval Status field.

Setup:

1. Set field permissions on the Approval Status field to "Only specific collaborators"
2. Add only the Cash Owner to the allowed list
3. Everyone else sees the Approval Status field but cannot edit it

Team members open the record, fill in their fields, and see the Approval Status. The Cash Owner opens the same record and can toggle it between Pending, Approved, and Rejected. No separate interface or form is needed.

Using This With Interfaces

If your team works primarily through an Interface, field permissions carry over automatically. A user who cannot edit a field in the base also cannot edit it through the Interface, even if the Interface marks the field as editable.

This makes it straightforward to build a single Interface for a mixed team. Set the fields editable in the Interface layout for everyone, then use field permissions in the base to restrict which users can actually make changes. The article on using base-level field permissions to control editing in interfaces walks through this pattern with a worked example.

Plan Requirement and Limitations

Field-level editing permissions are available on Team, Business, and Enterprise Scale plans. They are not available on Free plans.

On Free plans, the alternatives are:

• Use separate Interfaces with different field configurations (one Interface where the field is editable, one where it is not)
• Use a form that only shows the fields the person should fill in, rather than giving direct base or Interface access

Field permissions also cannot restrict access based on dynamic conditions. For example, you cannot say "only let a user edit this field if they are the record owner." The restriction is per-user, not per-record. For more complex conditional editing logic, an automation or a dedicated portal tool like Softr is a better fit.