Airtable permissions are simple on the surface — five roles, a few checkboxes — and surprisingly deep underneath. A workspace, base, table, view, field, and interface can each carry their own permission rules. Get this stack right and one base can safely serve a CEO, a marketing manager, three editors, two freelancers, and an external client without anyone seeing what they shouldn't.
Get it wrong, and either someone deletes a column or your team is asking an admin to update a status every Monday. This guide walks through how Airtable's permission system actually works, the five user roles you'll use, and the patterns we apply when setting up access for real teams.
The Six Permission Layers
Airtable permissions stack from the outside in. Each layer is more granular than the last.
| Layer | What it controls | Plan needed |
|---|---|---|
| Workspace | Default role across every base in the workspace | All plans |
| Base | Override of workspace role for a single base | All plans |
| Table | Restrict who can see or edit a whole table | Business+ |
| View | Lock view configuration so collaborators can't reorder it | Team+ |
| Field | Make a field read-only or limit who can edit it | Business+ |
| Interface | Per-interface access independent of base access | Team+ |
The rule for resolving conflicts is simple: the most restrictive layer wins. If you're a Creator at the workspace level but the table is marked read-only for your role, you can't edit it. If a field is locked, even Owners can't change it without unlocking it first.
The Five Collaborator Roles
Every Airtable user gets one of five role levels at the workspace, base, or interface layer. Each role inherits from the one below.
| Role | Can do | Can't do |
|---|---|---|
| Owner | Manage workspace, billing, all bases, all settings | Nothing — full control |
| Creator | Add/remove tables, fields, automations, interfaces; edit data; invite collaborators | Manage billing or delete workspace |
| Editor | Add, edit, delete records; add comments; can't change schema | Add or rename fields; create automations |
| Commenter | View records; add comments and @mentions | Edit or add records |
| Read-only | View records and views | Comment, edit, or change anything |
A good mental model: Owners handle money and ownership, Creators build the system, Editors run the system, Commenters discuss the system, Read-only users watch the system.
For a deeper dive on what each role means day-to-day, see our Airtable collaboration guide.
Step 1: Set Workspace Permissions First
The workspace is where most teams get the foundation right or wrong. A workspace role applies to every base inside it by default — so a workspace Creator is a Creator on every base in that workspace, unless you override it at the base level.
To set workspace permissions:
- Open the workspace from the Airtable home screen.
- Click Share in the top right.
- Add collaborators by email and pick their workspace role.
- Save.
We recommend exactly one workspace Owner per business — usually the person who owns the billing relationship. Add a second Owner only as a backup so the workspace isn't orphaned if the primary Owner leaves. Make your core build team Creators at the workspace level. Make everyone else (Editors, freelancers, clients) a collaborator on individual bases instead — never the whole workspace.
Quotable fact: A workspace Owner is the only role that can change billing or delete the workspace, and Airtable will not transfer Owner rights without a manual support request if the original Owner's account is closed. Always keep two Owners.
Step 2: Add Base-Level Collaborators
For each base, you'll often have collaborators that don't belong at the workspace level — a freelance designer on one project, a client reviewer on another. Add them at the base level.
- Open the base.
- Click Share in the top right.
- Add the collaborator by email and pick the base role.
- Optionally set them as an Interface-only collaborator (covered below).
The base role overrides the workspace default for that user. If a user is a workspace Editor but you make them a base Creator, they can build structure on that one base but not on others.
A common mistake: making a freelance designer a Creator on a base because they want to add a single view. They can also delete tables, change automations, and break the schema. Make them an Editor and create the view yourself — or use a personal view that only they can see.
Step 3: Lock Down Tables and Views
Once your collaborators are in, you'll want to control what they can do once they're inside the base.
Table permissions (Business+). Right-click a table tab, choose Edit table permissions, and decide who can edit records in that table. You can set:
- Anyone with base access can edit — the default.
- Only specific collaborators can edit — pick by role or by named user.
- Locked — nobody can edit until unlocked.
View permissions (Team+). Each view has three lock states:
| Lock state | What it does |
|---|---|
| Collaborative | Anyone with base access can change filters, sorts, hidden fields |
| Personal | Only you can see and edit this view |
| Locked | Nobody can change the view's configuration until it's unlocked |
Use Locked views for any view that an automation or interface depends on. The number of times we've seen an automation break because someone changed a view's filter is too high to count. Lock the view, leave a note in the view description, and create separate "scratch" views for ad-hoc filtering.
Step 4: Field-Level Permissions for Sensitive Data
Field-level permissions are Business and Enterprise plan features, and they're the cleanest way to hide a column from people who shouldn't see it.
To set field permissions:
- Right-click the field header.
- Choose Edit field permissions.
- Pick from Editable by anyone, Editable by specific collaborators, or Read-only.
- If choosing specific collaborators, add the users or roles allowed to edit.
The three patterns we use most:
- Lock all formula and rollup fields as Read-only. They're calculations, not data. Editors should never be converting them to text by accident.
- Restrict salary, cost, and margin fields to a specific group. Marketing doesn't need to see what each freelancer charges.
- Make ID and timestamp fields Read-only for everyone except admins. These should be system-managed, never edited.
On the Team plan, the workaround for missing field permissions is to build a synced base that omits the sensitive fields and share the sync rather than the original. We cover this pattern in our two-way sync guide.
Step 5: Configure Interface Permissions
Airtable Interfaces are where most teams now expose data to non-builders. Interface permissions are independent of base permissions — you can give someone access to an interface without giving them access to the underlying base at all.
To set interface permissions:
- Open the interface.
- Click Share in the top right of the interface canvas.
- Add the collaborator and pick their interface role.
The interface roles mirror the base roles (Editor, Commenter, Read-only) but apply only to that interface. The key option is Interface-only access — the user can use the interface but cannot open the base behind it.
Interface-only seats are how most agencies deliver client portals. The client sees a polished dashboard with the records they care about. They never see the messy automation table, the staging views, or the cost fields. From their perspective, the interface is the app.
Choosing Between Sharing Patterns
A common question: should I share a view link, invite someone as a base collaborator, or give them interface-only access? Here's how we choose.
| Scenario | Best pattern | Why |
|---|---|---|
| One-time status report for a stakeholder | Shared view link (public URL) | No account needed, read-only |
| Recurring client review of project progress | Interface-only collaborator | Branded experience, no base access |
| External agency partner editing a shared task list | Base Editor | Needs to write data, full record context |
| Customer-facing public catalog or directory | Shared view link with password | Public-friendly URL |
| Internal manager needing live dashboard | Interface-only or full base Read-only | Depends on whether they need filters |
Shared view links are the lowest-friction pattern but also the leakiest — anyone with the URL can open it. Use a password and turn off the "allow downloads" toggle if the data is sensitive. For ongoing access, interfaces or full base seats are always cleaner.
For the official documentation on share link options, see Airtable's sharing docs.
Locking the Base Against Schema Changes
Even with the right roles, Creator-level users can still make changes that break automations and interfaces. We use a few patterns to prevent this.
1. Lock critical views. Any view referenced by an automation or interface gets locked. Add a 🔒 prefix to the view name so it's visually obvious.
2. Lock automation source tables. Set the table permissions for any table that drives automation logic to "specific collaborators only," limited to admins.
3. Disable comment notifications on lock-breaks. If a Creator unlocks a locked view to "just check something," Airtable doesn't notify anyone. Use a scripting automation that periodically checks for changes to known critical views and posts to Slack if something moves.
4. Document the schema in a "Schema Notes" table. A simple table inside the base that lists which views, fields, and automations are critical. New Creators read it first, and it gives you something to point at when reviewing changes.
Common Permission Mistakes
We've audited dozens of client bases, and the same mistakes show up over and over.
Everyone is a Creator. It's easier to give people Creator than to think through what they actually need. Then someone renames a primary field and three automations stop working. Default to Editor; promote to Creator only when needed.
The base Owner is one person who left the company. When that person's account is closed, the workspace becomes orphaned and only Airtable Support can reassign ownership. Always have at least two Owners on every production workspace.
Sensitive fields hidden by view filters only. A hidden field is not a private field. Any Editor can unhide it. If the data is sensitive, use field-level permissions (Business+) or move it to a separate base.
Sharing a view link publicly with PII. Shared view links are not authenticated by default. Anyone with the URL can open them. If the view contains client contact info, internal pricing, or anything else that shouldn't be on the open web, add a password or move the data to an interface with proper login.
Letting clients into the base instead of an interface. Even with read-only access, clients in a base see your raw schema — your messy table names, your internal cost fields, your half-finished views. Use Interface-only access for every client, every time.
Troubleshooting: Why Can't This User Edit?
When a user can't edit something they should be able to, work through these checks in order.
- Workspace role. Are they at least an Editor at the workspace level, or do they have a base-level role that grants edit access?
- Base role. Has the base role overridden the workspace role to something more restrictive?
- Table permissions. Is the table locked or restricted to specific collaborators?
- View lock. Is the view locked? They can still edit data, but not the view configuration.
- Field permissions. Is the specific field they're trying to edit restricted to other users?
- Interface vs base. Are they trying to edit via an interface that has read-only settings, even though they have base edit rights?
If a user says "I can't edit this column," the answer is almost always field permissions or a locked formula field. If they say "I can't even open the base," it's interface-only access.
Where to Go Next
Permissions are infrastructure. They don't deliver value on their own — they protect everything else you've built from being broken by accident.
Once your permission model is solid, the next questions are usually about scaling: how do I share data across multiple bases without giving everyone access to all of them? That's where two-way sync and base architecture come in.
For team-wide rollouts, our Airtable collaboration guide covers comments, mentions, and shared view links in depth, and the pricing guide explains which permission features are gated to which plan tier. For programmatic access to Airtable that respects these permissions, see our personal access token guide.
Airtable's own permissions documentation is worth reading once when you set up a new workspace — the matrix of "who can do what" is the canonical reference.
