Airtable’s permission system looks simple until you actually need to give a client view-only access to one base without exposing three others in the same workspace, or let a contractor edit records but not touch the schema. The five roles are straightforward on their own; the confusion comes from where each one applies — workspace, base, or interface — and which plan tier you need before finer-grained control becomes possible.
The five roles, and what each one is actually for
Airtable has five permission levels: Owner, Creator, Editor, Commenter, and Read-only (sometimes shown as Viewer). A useful mental model: Owners handle billing and workspace ownership, Creators build and restructure the base itself, Editors run the day-to-day data work, Commenters discuss without touching data, and Read-only users just watch.
- Owner — full control including billing, deleting the workspace, and managing every other user’s access. Reserve this for whoever’s actually accountable for the workspace.
- Creator — can add/remove/rename tables and fields, change field types, build automations, and edit all records. This is the role that breaks things if handed out too freely — a Creator can restructure a base other people depend on.
- Editor — can add, edit, and delete records and use existing views, but can’t change the base’s schema (no new tables/fields, no automation edits). This is the right default for most day-to-day collaborators.
- Commenter — read access plus the ability to leave comments on records. Good for stakeholders who need to flag issues without any edit risk.
- Read-only — can view records and use filters/sorts within a view but can’t change anything, including comments.
Where permissions apply: workspace, base, and interface
These roles apply at three separate layers, and mixing them up is the single most common setup mistake:
- Workspace-level: the default role cascades to every base inside that workspace. Adding someone as a workspace Editor makes them an Editor on every base in it, not just the one they actually need.
- Base-level: you can override the workspace default for a specific base — for example, someone who’s a workspace Commenter can be bumped to Editor on just one base they actively work in, without touching their access to the rest.
- Interface-level: Interfaces (Airtable’s client-facing dashboard layer) have their own separate permission layer, letting you expose a curated view of the data — often Read-only or Commenter — to people who should never see the raw base at all. This is the right tool for external clients or vendors.
The practical rule: set the workspace-level role to whatever the majority of bases in it need, then override per-base for the exceptions, and use Interfaces (not raw base sharing) for anyone outside your organization.
Setting it up correctly, step by step
- Start at the workspace level. Go to workspace settings → Collaborators, and set a sensible default (Editor for most internal teams, Read-only if the workspace holds sensitive bases most people shouldn’t edit by default).
- Override per base as needed. Open the specific base’s Share menu and adjust an individual collaborator’s role there — this doesn’t touch their access to other bases in the same workspace.
- Use Interfaces for anyone external. Build an Interface layer over the base, then invite clients/vendors to the Interface directly with Read-only or Commenter access rather than adding them as base collaborators. They never see raw tables, formulas, or unrelated data.
- Lock fields on Business/Enterprise if you need sub-base granularity. Standard base-level roles can’t restrict access to just one table or field — if you need “this person can edit Table A but not Table B” within the same base, that requires field/table locking available on Business and Enterprise plans, or splitting the sensitive data into a separate base entirely.
Comparison: what each role can and can’t touch
| Role | Edit records | Edit schema (fields/tables) | Edit automations | Comment | View only |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | — |
| Creator | Yes | Yes | Yes | Yes | — |
| Editor | Yes | No | No | Yes | — |
| Commenter | No | No | No | Yes | Yes |
| Read-only | No | No | No | No | Yes |
The most common mistake: over-granting at the workspace level
The failure pattern shows up constantly: someone needs Creator access to fix one automation in one base, gets added as a workspace Creator “just to be safe,” and now has schema-editing rights across every base in the workspace — including ones with client financial data or HR records they were never supposed to touch. The fix is almost always the same: grant the narrowest role that unblocks the actual task, at the narrowest level (base or Interface, not workspace) that contains it.
FAQ
Can I restrict a Creator to editing only one table instead of the whole base?
Not with the standard five roles — that requires table/field locking on a Business or Enterprise plan, or moving the sensitive table into its own base with separate sharing.
What’s the difference between sharing a base directly and sharing an Interface?
Direct base sharing exposes the actual tables, formulas, and structure. An Interface is a built dashboard layer sitting on top — you control exactly which fields and records show, which makes it the safer default for anyone outside your core team.
Do permission changes apply retroactively to views someone already has open?
Access changes take effect close to immediately, but a collaborator’s browser may need a refresh before a downgraded role stops showing edit controls they no longer have rights to use.
Verdict
Airtable’s permission model is more capable than it first appears — the five roles cover most real needs, and the workspace/base/interface split lets you be precise if you actually use all three layers instead of defaulting everyone to workspace-wide access. Set workspace defaults conservatively, override per base for exceptions, and route every external collaborator through an Interface rather than the raw base.
