Advanced User Permissions


+1 on this feature request. I work with multiple clients who are submitting work orders and managing work in progress in an airtable base - but I also want to manage a different set of contractors who are doing the work on those work orders, as well as track expenses and revenue for those same work orders. Airtable views and columns make creating personalized views for each stage of the work possible, but the entire base data is available to all. As such, contractors know what other contractors get paid, as would the client, etc. etc.

We absolutely need to have some user permissions around hiding fields for certain collaborators and then it would be a perfect solution. Hmmmm. . . please?

Could possibly leverage a form for intake but even in that situation the client, if listed as a collaborator, would be able to expand to see the hidden fields (I think).

Linking between bases or sectioning collaborator permissions by Table could work too but I don’t think those are possible either. . .are they?



We need to a way for people to comment on certain tables but not view the entire base’s tables. Or a linking mechanism between different base tables where user access can be allowed on base one and denied on another.


I can’t believe it’s not possible to have different permission levels. I’ve spent many many hours working on a database for our institution and took for granted that I’d be able to keep some confidential information from some users. I use many many cloud applications and ALL of them have ways of limiting access and information.

So almost a year ago the airtable CEO said it was coming soon. Is it?


What do you want to hide? There is some methods, mainly with Views.


familiar with so called “personal” views etc. this is not a business level solution. Is there a business that doesn’t have confidential data that perhaps all collaborators should not have access to?


You want to hide Records, Fields, Views, Tables?


Requests for more granular access permissions have been beaten to death, but I recently shared this detailed use case/request with a member of Airtable support, so I’d like to post it here, as well – both for reference and to learn whether or not the community has discovered workarounds.

As a short-term vacation rental company, our primary AirTable Base stores the following types of data:


  • Property Detail (address, footage, etc.)

RENTALS (Table 2)

  • Rental Terms
  • Net Sales
  • Net Profits
  • Sales Team Member Commissions
  • AirTable Admin Formula Fields

As for our company structure, we’re made up of multiple departments (like most companies). Each department demands specific levels of access to certain types of data (also, like most companies). For example, here are 2 departments and the level of access they each require to the data types listed above:


  • EDIT: Property Detail
  • COMMENT: Rental Terms
  • VIEW: Net Sales
  • NO ACCESS: Net Profits, Sales Commissions, AirTable Admin Formula Fields


  • EDIT: Rental Terms
  • COMMENT: Property Detail
  • NO ACCESS: Net Sales, Net Profits, Sales Commissions, AirTable Admin Formula Fields

You may notice a similarity between the needs of the Sales Team and Rental Team: both sets of users require at least 2 permission types for data stored within the same Table. The current Airtable permission settings do not allow us to mimic this access structure.

We need granular access permission sets that can be applied “per user, per view”, as opposed to the current “per user, per base”. We’re not so much interested in restricting access to the records of our base, but more interested in restricting access to the columns/fields, and limiting which users can read and/or edit the content within these fields. It’s not enough to blanket each staff member with the binary option of “READ Everything inside the Base” or “EDIT Everything inside the Base”. There are too many nuances in between.

At the same time, “per user, per view” permissions are complicated to maintain, and perhaps too granular. Which leads me to my proposed compromise…

Certainly this is far easier said than done, but the most holistic, usable, and obvious solution (imo) would result from the addition of:


  • defined as groups of users who share identical access permissions for the data stored within a given Base
  • any given Team is unique to a single Base (i.e. the Base A “sales team” may be different than the Base B “sales team”)
  • all users must be on 1, and only 1, Team


  • users with EDIT permissions are now limited to creating (a) Personal Views or (b) Team Views
  • if a user creates a Team View, the access permissions for the new View will default to “VIEW” for all users on their Team, and “HIDDEN” for all other Teams (the Base Creator can later extend access to this View via the Team Panel).
  • thus, by definition, Team Views are Views which are HIDDEN from all but 1 Team
  • when sharing Team Views, login is required to access the share link (ensuring that users from other Teams cannot access); public share links are not allowed


  • accessed only by Base “Creators”, each Base has one “Team Panel” interface, but the settings within the panel will change respective of the “Team” that is selected from a Team dropdown (located within the panel)
  • the Team Panel lists all Views that exist within the base (regardless of which Team is selected), grouped by Table (see attached images)
  • adjacent to each View name is an access permission dropdown, which “Creators” use to assign the following access permissions to the selected Team: EDIT, VIEW, COMMENT, HIDDEN

To illustrate, here’s a very crude rendering of the Team Admin Panel:


Since Views are merely groupings of “Fields”, these additions would ultimately allow a clever Base Creator to assign granular permissions on a “per user, per field” level, if they so choose.

Consider a single user, John, who has the following access:

  • VIEW access to View A
  • EDIT access to View B

These permissions are better thought of like so:

  • VIEW access to all Fields of View A
  • EDIT access to all Fields of View B

Since John’s highest level of access is EDIT, he can add new Personal or Team View to the Base. If John were to create View C, he would have all Fields of View A and View B at his disposal in creating his new View C, but his ability to EDIT field data will be limited to the Fields of View B.


Great feedback. Please add your voice to Advanced User Permissions.


Great feedback. Ties in nicely with the Advanced User Permissions post.


Just realised I basically copied the above reply. In any case, it deserves two mentions.


effectively handed a well-developed feature idea on a silver platter. Pretty please team Airtable! I second this feature 100%.:pray::pray::pray: This is especially useful for teams collaborating with external contractors on project basis!


The lack of security is the one aspect which is making our company question whether Airtable is right for us.
User stories:
As the creator of a base, I want to share this base as read-only with other selected people.
As the owner of the data in the base I want to avoid anyone from sharing the read-only link outside a certain domain.

  • 1 to this post. This is 1 reason why our company doesn’t want to purchase airtable licenses… needs better security to hide certain tables/views from users.


Same here. A very needed functionality.


I want to be able to invite Collaborators to a Base, and have it to where they are only able to view/edit records they are assigned to.

What are the chances of this ever happening?


Any response from Airtable on this? Per-table security is a must!


Couldn’t agree more! As we look to leverage Airtable as an enterprise solution, the ability to set user permissions is huge! In our organization for example, we need the ability to provision someone into a workspace for a specific project task, without giving them access to everything in the workspace. Privacy is key as we have certain more ‘confidential’ projects we are working on at any given time. Would love an update on timeline for bringing this to the platform. Thanks Airtable!


Same. I have a view that I can share with my collaborator right now, but they can’t edit anything unless I add them as a user to the whole base.

Is there a way to restrict the editing to just one table, without giving them access to all tables in the base, at least?


Here is a pretty simple example that is NOT complex. The majority of Airtable’s users CAN comprehend a simple diagram. If they couldn’t comprehend the image below, Airtable wouldn’t even exist in the first place.

The amount of $$ in development of this feature will be paid back to Airtable in the matter of days with the amount of Enterprise customers switching over.

Here is an example of what is possible. Their system is very much set up like Airtables. I just don’t see why this is that big of a “technical hurdle”


Agreed. I cannot convince my directors to sign off on an Enterprise subscription until there is user or user-group level security.

It seems that a unix-like user-group system would work wonderfully. Attaching users to various groups, and groups to various views.

Most users do not need to create views.