Airtable Collaboration: Comments, Mentions, Permissions, and Shared Views

A solo person using Airtable doesn't need to think about collaboration features. A team does. The moment a second person opens the base, you need a story for how they comment on records, how they get notified when something changes, how their permissions differ from yours, and how you share specific slices of data with people who shouldn't see everything.

This guide walks through every collaboration feature with the patterns that work in real teams.

The Collaborator Hierarchy

Airtable has five collaborator levels. Each one inherits from the one below — Owner can do everything Creator can, Creator can do everything Editor can, etc.

A user's collaborator level is set per-workspace and can be overridden per-base or per-interface. Someone could be a Creator on the engineering workspace, an Editor on the marketing base, and a Read-only on the finance dashboard — all under one user account.

For a complete reference, see Airtable's Permissions and User Roles documentation.

Record Comments

The single most-used collaboration feature in Airtable. Every record has a comments thread.

To open it: expand a record (click the row's expand icon or open the record from any view), then click the speech-bubble icon. The comments panel appears on the right.

Comments support:

• @mentions of any collaborator on the base
• Markdown formatting (bold, italic, code blocks)
• Links that auto-detect URLs
• Threading — replies stay attached to the parent comment

When you @mention someone, they get a notification with a direct link to the record.

Patterns That Work

Record comments are most useful when they're the primary discussion surface for that record. A few examples:

• Approval workflows: the approver leaves a comment with their decision and reasoning. The record's status field changes too, but the "why" lives in the comment.
• Handoff context: when work moves between team members, the previous owner leaves a comment explaining what's done and what's next.
• Question threading: a junior team member tags a senior to ask about edge cases — the question and answer stay attached to the record for anyone who picks it up later.

Comments don't take up fields, so a record can accumulate hundreds of comments without bloating the data. They also don't appear in CSV exports, so they're safe for context the team needs but external recipients shouldn't see.

What Comments Aren't For

Two anti-patterns:

• Don't put data in comments. "Final price: $5,000" should be a field, not a comment. Comments are for discussion. Fields are for facts. The line between them defines whether the base stays clean.
• Don't use comments instead of automations. If you're commenting "@finance please process this invoice" every time, build an automation that does the notification.

Mentions and Notifications

When a collaborator is @mentioned, they receive a notification. Three channels:

1. In-app notification center. The bell icon top-right shows unread notifications.
2. Email. Sent based on user preferences — typically immediate, daily digest, or off.
3. Mobile push. Through the Airtable mobile app, if installed and notifications enabled.

Users can subscribe to records, tables, or specific automations to get notifications without being mentioned. This is useful when someone wants to know about every change to a specific record (the CEO subscribes to the Q4 OKR records and sees every status update).

Settings for notifications live in each user's profile — what type of activity warrants an email, how often, and which channels. As a team, agree on a baseline: too many emails leads to notification blindness; too few leads to missed updates.

Permissions Beyond Collaborator Level

The collaborator level is the headline permission, but Airtable has finer-grained controls.

Field Permissions (Business+ Plans)

You can set each field as:

• Editable by anyone with edit access (default)
• Editable by specific collaborators — only certain users can edit, everyone else sees but can't change
• Read-only — nobody can edit, even Creators

Common use cases:

• Salary or compensation fields — only HR can edit
• Status fields that should only change via automation — locked from manual edits
• Calculated fields — formulas naturally can't be edited, but lookup and rollup fields can be locked too
• Finance fields on a project record — only finance can edit

Table Permissions (Business+ Plans)

A whole table can be hidden from specific collaborators. The HR Sensitive Data table is invisible to anyone outside HR; they see the base without that table existing.

Combined with field permissions, you can build a base where finance, ops, and sales each see a different slice. No copies, no sync drift, just permissions.

View Permissions

Two layers here:

• Personal vs Collaborative views. Personal views are visible only to the creator. Useful for "I want to slice the data my way" without polluting the team's shared views.
• Locked views. Any view can be locked, which prevents others from changing its filters, sorts, or visible fields. Useful for views that drive automations — if someone changes the filter, the automation fires on the wrong records.

For more on view types and configuration, see our Custom Views guide.

Interface Permissions

Each interface page can be set to Read-only, Commenter, or Editor per user — independent of their base permissions. A user with Editor on the base might be set to Read-only on the executive dashboard interface so they can view but not change.

For more on interface design, see Interface Designer guide.

Sharing With People Outside Your Workspace

Three options, in order of permanence.

Option 1: Shared View Link (Public)

Right-click any view, choose Share view, get a public URL. Anyone with the link sees the view in read-only mode. They don't need an Airtable account.

You can:

• Restrict by password
• Restrict by email domain (paid plans)
• Disable copy/export
• Embed the view in a website or Notion page

Use shared view links for:

• Sending a client a live project status they can refresh anytime
• Embedding a public roadmap on your website
• Sharing a filtered dataset with a vendor for review

Don't use shared view links for sensitive data — anyone with the URL can see it.

Option 2: Interface-Only Access (Team+ Plans)

The Interface-Only seat lets you invite collaborators who can use your interfaces but cannot open the base. They see only the interfaces you share with them, and within those interfaces, only the data the filters expose.

Use Interface-Only for:

• Internal team members who shouldn't see the underlying schema
• Contractors who need to do specific tasks but not poke around
• Clients who need ongoing access to their portal-style view

This is cleaner than shared view links because it preserves audit trails (the user is logged in) and lets you build a real UI rather than just exposing a filtered grid.

Option 3: Softr Portal

For external users at scale (hundreds or thousands of users), Airtable's collaborator pricing becomes untenable. Build a Softr portal instead — Softr is a polished UI on top of Airtable that handles authentication for unlimited users at a flat cost.

Use Softr when:

• You have a customer-facing portal with many users
• You need a branded UI that doesn't look like Airtable
• You need user-level permissions and per-user data isolation

Filtered Per-User Access With "Current User"

The most underused trick in Airtable's permissions toolkit: the Current User filter.

Configure any view filter with {Owner} is Current User. The view now shows different records to each viewer — each person sees only the records assigned to them. One view, hundreds of users, perfectly personalized.

Common applications:

• A "My Tasks" view that shows each user only their tasks
• An interface page filtered to the logged-in user's account manager assignments
• A leave-request table where each user sees only their own requests

This works for collaborators, interface users, and Softr portal users. It's how you avoid building one view per user.

Activity History and Auditing

Every change to every record is logged. Open a record, click the expand icon, look for the activity panel.

The activity log shows:

• Field changes (who changed what from what to what)
• Comments added
• Records linked or unlinked
• Status changes (with before/after)

Retention varies by plan — typically several months on Team, longer on Business and Enterprise. For compliance use cases requiring permanent audit trails, you'll want to export activity periodically or use Airtable's enterprise audit log API.

Real-Time Collaboration

When multiple users open the same record or view, you'll see their cursors and any changes they make in real time. There's no save button — changes commit as you type.

Conflict handling is straightforward: the last write wins. If two users edit the same cell simultaneously, the most recent edit replaces the earlier one. For text fields this can cause minor frustration, but for the typical Airtable use case (status changes, single-cell updates), it's rarely an issue.

For genuine document-style collaboration (multiple people writing the same long text together), Airtable's long-text fields handle it but you're better off using Google Docs or Notion and linking to the doc from the Airtable record.

Common Permission Mistakes

A few patterns that cause problems in growing teams.

Everyone is a Creator. It's tempting to give everyone Creator access so they can build their own views and automations. The downside: someone accidentally deletes a field or breaks an automation. The fix is to use Editor by default and promote to Creator only when needed. Most users on a mature base are Editors.

External users with full base access. A client who shouldn't see internal pricing fields gets invited as a Read-only on the whole base. They can see everything; they just can't change it. Use field permissions or sync to a smaller "client-facing" base instead.

Shared view links with sensitive data. A team member shares a view link in a Slack channel that includes confidential records. The link is public. Use interface-only or Softr for sensitive data; reserve shared view links for genuinely public-friendly data.

No locked views. Automations that trigger on view membership are fragile if anyone can edit the view's filters. Lock the views that drive automations.

A Quick Reference for Team Setup

For a typical small-to-mid team setting up Airtable from scratch:

Adjust based on your team's risk tolerance and how distributed responsibility is.

Where to Go Next

For the interface side of collaboration — building per-role dashboards and workspaces — see our Interface Designer guide. For external-facing portals beyond Airtable's collaboration features, the Softr client portal tutorial covers the broader pattern.

For Airtable's full permissions documentation, see collaborator types and permissions.