Advanced User Permissions

+1 for this suggestion. This is the single biggest product gap that prevents us from incorporating Airtable more broadly into our company workflows. It really limits the power of using Airtable as a centralized single source of truth if different groups can’t be restricted to collaborating and editing subsets of that overall data. While there is not single permissions solution that fits everyone’s needs and also maintains simplicity of UI, it seems that table and view level permissions as a starting point would cover a lot of use cases. Are more granular permissions still on the roadmap? I expect it influences continued user investment in airtable vs alternative solutions for many.

3 Likes

Defiantly need table level security permissions!! It is silly that i need to give write access to every table in the base just so that they can edit one table. ;(

3 Likes

Field-level permissions, please!! We need to give our partners (who aren’t so trustworthy when it comes to data integrity) the ability to update individual fields WITHIN views, and not just the whole view or base.

3 Likes

The ability to restrict users to set views/filter combinations is what is stopping us from upgrading to the paid plans. It would be a lifesaver to upload data that only some users can see but right now it is all or nothing.

3 Likes

we use airtable to keep track of loans detailing data for our clients. it’s pertinent that only certain individuals can see all the bank’s data while loan officers can only see the loans they are assigned to (chosen by the collaborator field). There is NO WAY to currently restrict certain views to a collaborator. When I assign commenting or editor permissions it’s either all or nothing.

3 Likes

As Howie and myself have previously mentioned, “Advanced User Permissions” is a massive category of potential features. In this thread alone, people have suggested dozens of potential implementations, each of which has its own set of unique considerations. I can say that granular permissions are a high priority for our product team and we do intend to keep adding support for such controls as we grow.

At the same time, the development of more permissions features is a very complex project. The different potential ways in which these features could be implemented each have massive and far-reaching implications for how teams access and interact with their most important, mission-critical data . This is a responsibility that we take extremely seriously, and as such, we need to take every necessary precaution in order to ensure that we have thoughtfully considered all possibilities.

As just one example of the kinds of questions we need to ask ourselves: when thinking about the broad category of “limiting access” for certain users, does this mean limiting the ability to see information, to make changes to information, to share information, or something else entirely? We are actively thinking about permissions as it relates to all of these different actions, but at the same time, each of those actions is itself an extremely broad topic encompassing many different use cases, design decisions, technical challenges, and implementation concerns.

Furthermore, for any feature that we implement, we have to carefully consider how it will interact with all of the other features that already exist in the product (e.g. linked records, forms)—as well as any features that we might implement in the future . Again, these kinds of considerations are of vital importance when it comes to issues of information access, editing, and sharing.

On top of all that, our product team needs to carefully balance the desires of individual users to add ever more features that solve specific needs with the collective value for everyone that comes from having a product that is as welcoming and accessible to as many people as possible—without becoming heavyweight or overwhelmingly complex.

To reiterate what Howie has already said, there’s no such thing as a “one-size-fits-all” model for granular permissions, so there won’t be a day when we suddenly release a silver bullet that solves all permissions needs for all users. Instead, our current focus is on developing more narrowly scoped feature-components that will allow users to build out the permissions systems that they need (e.g. our releases of locked views, limiting visible options in forms, etc.). We will continue to keep you updated on all new features (permissions-related or otherwise) as they become available, as well as any relevant pre-general release betas.

Lastly, by far the most helpful thing that you can do to regarding this topic is give us specifics of your use cases and the problems you’re facing. Plenty of folks in this topic have done just that, for which our product team is grateful. Here are just a couple of example questions touching on the topics that concern our product team:

  • What industry do you work in? What role do you have? How are you using Airtable?
  • Are you most concerned with view access, write access, share access, or another form of information access?
  • Who are you using Airtable with? With other Airtable collaborators? If so, are these other collaborators base or workspace collaborators? Or, are you using Airtable with non-Airtable users? If so, are they using forms? How are they using these forms?
  • What is the nature of the information that you’re concerned about? Where does it live? In specific cells? In records? In fields? In field configurations? Just in specific views? In entire tables? In the names of records, fields, or tables? In share links?
  • Do you use linked records at all? If so, how would you expect that linked records would interact with more granular permissions?
5 Likes

I’m working on a product on top of Airtable that I believe will help with some of these uses cases: particularly those around providing portal access for clients to a subset of records in a base. We’ve just opened our beta list, you can sign up here: https://airportal.app/

@Katherine_Duh I would love to speak to you about this so we can align our offering with the underlying platform’s direction.

1 Like

Hey @Katherine_Duh, I’m a former dev and looking to use Airtable for our growing business. We make wedding rings and they go through various stages (new, reviewed, being made, shipped, etc). We have different internal teams that need access to some records that have progressed a certain stage, but not others. For example, the people interested in records that are in the “being made” stage may need to add themselves as the maker of the ring. But, we don’t want those people accidentally deleting fields like the ring description or customer data. Or, changing the status to something else.

We could actually do OK with locking fields down at the view level. We would have a main table that has all of the data, then just have views for various departments. If we just had an option on the views to make certain fields read-only, that would likely solve many of the issues regarding permissions. Maybe collaborators can still change those fields, but not editors?

Thanks

3 Likes

The lack of these granular field level permissions are what’s keeping me from going all in with Airtable. This is a must!

5 Likes

Despite what the airtable staff says, I think there IS a “one-size” solution here: simple give those with “Creator” or “Owner” permissions the ability to set which views are viewable by which collaborators (and then restrict collaborators from being able to edit the views of course).

Another alternative is to create another permission level in between Commenter and Editor. Someone who IS able to edit the data in records but NOT allowed to change the views and/or filters of the table they are working in. This would allow whoever configures the table (owner/creator) the ability to hide or show certain columns of data as needed.

It’s a very simple fix and I’m baffled airtable has not gotten on top of this yet.

4 Likes

All that is needed is a permissions level in-between commenter and editor.

Someone who can change the data in the fields but who can NOT change views.

Alternatively you can take away the ability Editors have to change views and restrict that to the owner/creator.

Virtually all other problems would be solved this way because only the creator/owner would have the ability to control who sees what by filtering columns from the pre set views and then settings those views to certain users.

4 Likes

one solution that could fit all (since it remains our responsibility to handle the granularity): give edit permission to a user only on specific views.

So airtable’s users can prepare specific views (hide fields, use filters as needed) and give access to another user to edit what need to be edited. This “editor” would have power to edit only what is visible in this view, can not see other views, neither other tabs of the table.

What do you think @Katherine_Duh ?

one solution that could fit all (since it remains our responsibility to handle the granularity): give edit permission to a user only on specific views.

So airtable’s users can prepare specific views (hide fields, use filters as needed) and give access to another user to edit what need to be edited. This “editor” would have power to edit only what is visible in this view, can not see other views, neither other tabs of the table.

What do you think @Howie_Liu

1 Like

Me Too! Please for heaven sake give us some granular permission settings :wink: Airtable is awesome and has so much potentials but without a few fundamental capabilities its use cases are limited.
We have started testing Airtable in our organization and definitely would shift our business into Airtable if we could have some extra features, permission settings being on the top.
Thank you

4 Likes

This is make of break for us.

We can’t have an external collaborator access tables where we keep private data (eg. financials).

Surely setting access at table level i something that can be rolled out painlessly? Or maybe not.

Here’s my contribution:

  • What industry do you work in? What role do you have? How are you using Airtable?

Tech, as Marketing Manager. I’ve built out a base to track programs of work, campaigns, content production and tasks. And all the financials.

  • Are you most concerned with view access, write access, share access, or another form of information access?

I don’t want specific collaborators to be able to access specific tables. Good if all of the above can be set for each too.

  • Who are you using Airtable with? With other Airtable collaborators? If so, are these other collaborators base or workspace collaborators? Or, are you using Airtable with non-Airtable users? If so, are they using forms? How are they using these forms?

1. Freelance copywriters. I can set up tables for each to keep them separate (a requirement) but would be happy to limit view of records for a single table based on their association to a collaborator. So freelancer Jo Smith can only see his / her records.

2. Developers. Same as above.

  • What is the nature of the information that you’re concerned about? Where does it live? In specific cells? In records? In fields? In field configurations? Just in specific views? In entire tables? In the names of records, fields, or tables? In share links?

Info lives in all of the above, of course.

Happy to have permissions set at table level.

  • Do you use linked records at all? If so, how would you expect that linked records would interact with more granular permissions?

Extensively.

If a collaborator does not have access to a table then I wouldn’t want them to see the linked records in another.

This post was flagged by the community and is temporarily hidden.

2 Likes

Just to add my use here, and hoping this will progress!

I’m using Airtable as a project management tool. We’re a small team but do involve external users on some of our bases. I’m mostly concerned with write access here, but view access is also something that would be highly useful. All collaborators are base collaborators only as we have a lot of quite different bases.

As an example, I build a base for a major event that requires links between key deliverables, tasks, and promotional content. e.g. a web page launch requires design and development tasks, but also linked to social media promotion once launched. Currently these three tables are viewable by all, but it would be useful to hide one or more depending on role - the external developer does not need to view the social content plan.

Restricting write access would also be very useful. For example, the external developer should not need to edit the fields I create for their task, but should be able to change the progress column from ‘In progress’ to ‘For review’, or check the ‘Done’ checkbox column, for example. Currently if I need anyone to do anything more than comment I need to give them the ability to edit the whole record, and trust that they will leave it alone. And as Airtable updates in real time, it’s not just about trust, but guarding against mistakes.

So what I’d love to be able to do is:

  1. option to hide whole tables from certain users
  2. ability to restrict ability to edit certain fields
  3. ability to restrict records - for example, only allow users to view/edit records that they are collaborators on.

We use linked records a lot. I’d expect the behaviour either to show any that the user doesn’t have permission to view in a slightly ‘greyed out’ design with no ability to click through, or simply missing.

Thanks!

Why has this post been hidden?