Again running into issues with not having more granular control of User Permissions. Wondering if this is on the Roadmap and if so (Though I know you can’t say when) is it one of the higher priority items?
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?
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.
