Airtable interfaces: separate interface-only and base access

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Distinguish the sharing surfaces

Airtable's base Share control grants access to the base, its data, automations and published interfaces at the selected permission level. Share interface can grant access only to an interface and its published pages. A collaborator who already has base access is not narrowed by a separate interface invitation; remove the broader base or workspace access first if the intended role is interface-only.

Build a role-and-record fixture

Use a fictional request base with one public test record, one record assigned to the current user and one restricted record. Preview the interface as a read-only base collaborator, interface-only viewer and interface-only editor.

Reconcile all permission layers

Interface filters can show all records, specific records or the viewer's records when the required user field exists. Table and field restrictions configured in the base continue to apply inside interfaces. An Add Record control or editable visualization does not override a table or field restriction.

1. List every workspace, base and interface grant.
2. Choose the minimum role for the intended task.
3. Configure record filters using synthetic assignments.
4. Preview or view as each role.
5. Test read, comment, edit and create actions separately.
6. Remove unintended broader access before inviting again.
7. Review sharing restrictions and pending access requests.

Accept least-privilege access

Accept the design when each role sees only the expected records and can perform only the declared actions. Current plan, account verification and SSO requirements must be checked in the real workspace rather than inferred.