@Airtable_Support has there been any progress/updates on this? What would be beneficial for me is (as an owner) be able to create “personal views” and specific tables for my sales members, where the filters and hidden fields that “I set up” can not be modified by the sales member. I would like to be able to have 1 table with all sales by the whole sales team but they can only see their sales.

So as the “base owner” i need to see all views that i create, but i want my sales team to only see the views that i allow them to see. They should not be able to remove filters or unhide fields that i set. If they are able to create personal views then those personal views should also include the filters and hidden fields that i have created in their primary view.

I would also like to be able to hide entire tables from some or all other members as well.

I guess the easiest way to do this would be to add a “Hide” feature to entire tables, or hiding specific views and or columns within a table from “All members” or only the “Selected Members”. Having these additional permission levels to Tables, Views and Columns would be great.

I do understand that using the API this can be done on my website BUT, a big part of the reason for using Airtable directly is the ease of use for your mobile apps and having the ability to just open the Airtable app to view, edit or add data on the go with a view that looks great on a mobile device vs everyone having to log into the website everytime to make adjustments. I would imagine that this is the case for most of us

Please Please Please make this happen!

I’m sharing the entire base with a client because he must be able to edit a very specific set of data (one table). But doing so they can edit my entire base, screwing all the system at will and, more importantly, they can see ALL the data of ALL the tables (eg. other clients tables). Which is absolutely a no go for my specific case

Working with a nonprofit with sensitive user data. We need to specify which users have access to sensitive information in columns. right now, I plan on exporting the airtable to an excel sheet that has coded fields in place of names/identification. But that’s not a good solution. We may have to move entirely off of airtable to excel, because it’s easier for us to code sensitive data.

Is their a timeline for this? @Howie_Liu

I am also eager for some level of permissions on tables (or possibly fields).

We use Airtable to manage projects for a design company. It’s meant to be a central project tracking source for the entire company. That includes financial information related to the project that, frankly, not everyone needs to see.

One option we’ve considered is duplicating the project info into a separate base, but that defeats the purpose of having a centralized system.

I’m disappointed that years later after this thread began, there are still no developments on this front and no updates from the Airtable team as to progress or what to expect. I’m hoping this is still actively being worked on.

Hi there, I second what Jon_Thomas said - I want a central project tracking base for the entire company but I don’t want most of the employees seeing the financial side - there should be a permission level that doesn’t allow them to create new views so that they can’t see any columns you have hidden from their view but still allows them to edit. And you should be able to assign collaborators to specific views in such a way that they can’t see other views or make new views that would allow them to see columns that have been blocked from them. If you could make it so that they can move their visible columns around within their view to their preference and sort/filter only the viewable columns, that would be even better, but even adding a permissions level where they cannot make new views or change the views you assign to them would go a long way. This should be a top priority for Airtable, as it is vital. \

Also, and this is a bit different but… being able to lock columns in a view so that, say, an employee can see how many hours of their time were budgeted for a project but can’t accidentally change it.

we can make main view write only and rest all linked tables with options as read only !!

Any ability to tie filtering capabilities to certain permission levels would be a lifesaver. To my knowledge, it still is not possible to have only part of a base viewable and editable by a specific user - which is deeply frustrating.

this is so so desperately needed and probably the biggest weakness Airtable currently has vs. google sheets

I use Airtable in the volunteer management space, which involves a lot of Personally Identifiable Information, and from a data security perspective I need to be able to share as little PII as possible at all times. However, I still need to have the full info stored in airtable for when we DO need it.

The ability to set permissions at the view level would totally solve this. Any updates on this feature?

+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.

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. ;(

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.

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.

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.

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?

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.

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

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

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.

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.

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

Me Too! Please for heaven sake give us some granular permission settings :winking_face: 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

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.

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!