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?
You all are awesome. Thanks!
Page 8 / 11
Why has this post been hidden?
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?
Thanks for this thorough answer @Katherine_Duh! Really helpful in giving us perspective. Can’t wait to see how the team at Airtable tackle this.
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?
There currently isn’t a way to prevent a user (even at read-only) from duplicating and stealing an entire base.
Regardless of how granular permissions CAN get, that’s just totally unacceptable from a security perspective. Once discovering it, we had to move entirely off of airtable. Our bases contained information that are valuable because we pay for it and they directly relate to the bottom line. Allowing any type of user to copy the entire thing is really a critical development flaw.
Another vote to prevent record deletion…
When developing user experiences, the key rule is “Don’t make me think”; the bigger the manual, the greater the failure at achieving this goal. Now lets add additional systems into the mix for which Airtable is the system of record. Airtable has a nice API, but you can only read from and push to Airtable; Airtable can’t notify external systems when records are deleted. When users haven’t read the manual and delete records in Airtable, the auxiliary systems are now out of sync.
This situation will get worse over time because the initial users of the system may have it drilled into their heads not to delete records, but they’ll get promoted or leave the company and their successors may not have a good hand-off, the institutional knowledge will be lost, eventually someone will “clean up” the data in Airtable and now data within the various systems are completely out of sync.
Now you need to create a data validation system which will periodically compare data within the various connected systems to find and fix the orphans. All because Airtable doesn’t allow me to prevent record deletion.
(My primary concern is as a data integrator, I need to either prevent record deletion or be able to read a list of deleted records. Since preventing record deletion is too difficult, how about adding a filter that would allow me to retrieve a list of records in a given table that were deleted within the last x minutes?)
Me:
Software Product Designer
Small business owner
Trying to love Airtable
User need cases - based on this thread
- restrict data access by users with varying levels of access needs (by field / by view / by base etc)
- prevent unwanted deletion
Airtable product concerns
- Keep things simple
- Keep permissions from becoming barrier to productivity
Comments
Airtable rightly knows its ideal customers are likely to be non-enterprise level teams looking for simple (yet powerful) solutions. Nobody wants complicated permission groups / tiers / and layers.
Solution
Views. They currently have all the building blocks of a structured permission system.
- Locked view is already a flag on a view that allows modification or not. Separate this out from “Personal” they are not mutually exclusive states.
- Hidden fields. Combined with locked views, we now have granular control over both and edit permissions. (view permission already = shared links)
- Now add per-user access to views. Kind of already exists with personal views, which is a single user association to a view. Now open that association to multiple users.
- Finally, a user permission tier that can edit records but cannot create or alter views. Both functionalities already exist within Editor and Commenter permissions.
- Finally ho’s able to configure the user to view associations? Creators only.
Me:
Software Product Designer
Small business owner
Trying to love Airtable
User need cases - based on this thread
- restrict data access by users with varying levels of access needs (by field / by view / by base etc)
- prevent unwanted deletion
Airtable product concerns
- Keep things simple
- Keep permissions from becoming barrier to productivity
Comments
Airtable rightly knows its ideal customers are likely to be non-enterprise level teams looking for simple (yet powerful) solutions. Nobody wants complicated permission groups / tiers / and layers.
Solution
Views. They currently have all the building blocks of a structured permission system.
- Locked view is already a flag on a view that allows modification or not. Separate this out from “Personal” they are not mutually exclusive states.
- Hidden fields. Combined with locked views, we now have granular control over both and edit permissions. (view permission already = shared links)
- Now add per-user access to views. Kind of already exists with personal views, which is a single user association to a view. Now open that association to multiple users.
- Finally, a user permission tier that can edit records but cannot create or alter views. Both functionalities already exist within Editor and Commenter permissions.
- Finally ho’s able to configure the user to view associations? Creators only.
Oh yeah, deletion.
Just keep a accessible log of deleted records. You do already have that right? Let us see who done it and recover.
Me:
Software Product Designer
Small business owner
Trying to love Airtable
User need cases - based on this thread
- restrict data access by users with varying levels of access needs (by field / by view / by base etc)
- prevent unwanted deletion
Airtable product concerns
- Keep things simple
- Keep permissions from becoming barrier to productivity
Comments
Airtable rightly knows its ideal customers are likely to be non-enterprise level teams looking for simple (yet powerful) solutions. Nobody wants complicated permission groups / tiers / and layers.
Solution
Views. They currently have all the building blocks of a structured permission system.
- Locked view is already a flag on a view that allows modification or not. Separate this out from “Personal” they are not mutually exclusive states.
- Hidden fields. Combined with locked views, we now have granular control over both and edit permissions. (view permission already = shared links)
- Now add per-user access to views. Kind of already exists with personal views, which is a single user association to a view. Now open that association to multiple users.
- Finally, a user permission tier that can edit records but cannot create or alter views. Both functionalities already exist within Editor and Commenter permissions.
- Finally ho’s able to configure the user to view associations? Creators only.
Thanks Peter. Reading through the whole thread above the focus has been mainly on accidental deletion or seeing figures and general info that isn’t relevant. We would have significant personal and in the UK specifically GDPR issues (affects personal data) without the ability to lock down views. I suspect many potential UK users will not be able to proceed without more granular permissions. Your solutions would appear to solve these for us.
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?
All we really need is another switch on the Duplicate Base options to set a ‘Do not allow Editors to duplicate this base’ - keeping this permission at a Creator / Owner level.
- What industry do you work in? What role do you have? How are you using Airtable?
We are a business which has developed a business change and planning methodology. I’m the COO, and have translated our methodology from a spreadsheet based approach to use Airtable.
For data privacy and segregation, we set-up a new base for each project/client and provide the Practitioner / PM editor access to this base. They use this to manage their project, and may give clients viewer or editor access to the base.
- Are you most concerned with view access, write access, share access, or another form of information access?
Our #1 concern is being able to stop the duplication of a base. This is for 2 reasons:
a) The base is the codification of our IP - we want to control how this is spread and stop it being copied without permission.
b) We want to give our practitioners control over how clients access the project data.
We are essentially using Airtable as the MVP of our toolset before developing a stand-alone app.
- 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?
All collaborators are Base collaborators.
Practitioners are typically Editors
Clients typically engage via forms and read only Table View links
One client role may be given editor access to the base - this is case-by case.
- 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?
We are concerned primarily about the protection of the base as a whole rather than individual data elements.
While some degree of role-based permission / data segregation would be useful, this is not critical for us at this stage of development.
- Do you use linked records at all? If so, how would you expect that linked records would interact with more granular permissions?
Yes, but as we are not concerned with role based data access, this is not a concern for us.
Can we PLEASE have it so we can turn off base cloning ability?!
Protecting sensitive client information / formulas is a big deal for us. All it would take is hiding a single button for anyone that is not an admin 
Thank you for all that you do! Love Airtable.
If you want to allow someone to edit only certain fields, we’ve created a tool that allows you to do that. It generates a basic editor that’s ideal for giving access to users who just need to do light work.
Basic Editor with Advanced Permissions for Airtable - miniExtensions
Share a basic editor for Airtable View with a password-protected URL
Hi there!
We, at Bevouac, are huge fans of Airtable. It (almost) suits our needs perfectly!
The one feature that would make us use only Airtable and not “home-made code” or other tools would be the possibility to share only a portion of the base (one table and selected views i.e.) to an external user and give that person the ability to edit or add records.
When will you take on developing such a feature?
Thanks for your answer.
Is this what you’re looking for?
Thanks Bill! It partially does indeed!
I recently asked to be able to test out this beta feature (still haven’t had the chance).
Yet, this doesn’t seem to handle the issue : “How can I adjust who can see information in my base?”
Thanks Bill! It partially does indeed!
I recently asked to be able to test out this beta feature (still haven’t had the chance).
Yet, this doesn’t seem to handle the issue : “How can I adjust who can see information in my base?”
I agree, and I believe this needs to be addressed by someone intimate with the security architecture. And I suspect - with these soon to be available features - there may be clever ways to address this requirement.
But, based on this beta, it seems the team is on the right compass heading.
Is this what you’re looking for?
We have been using the beta and it is terrific - solves a lot of problems re: user permissions. However, I don’t believe it addresses the ability to only allow users to see selected information. Hopefully that is the next step for Airtable’s development team as it would be very valuable.
We have been using the beta and it is terrific - solves a lot of problems re: user permissions. However, I don’t believe it addresses the ability to only allow users to see selected information. Hopefully that is the next step for Airtable’s development team as it would be very valuable.
The one feature that would make us use only Airtable and not “home-made code” or other tools would be the possibility to share only a portion of the base (one table and selected views i.e.) to an external user and give that person the ability to edit or add records.
Hey guys, i had the same issue so we built a way to sync base together so we can share a portion of base with edit access to our clients.
We are thinking of sharing it, if you are interested click here
The one feature that would make us use only Airtable and not “home-made code” or other tools would be the possibility to share only a portion of the base (one table and selected views i.e.) to an external user and give that person the ability to edit or add records.
Hey guys, i had the same issue so we built a way to sync base together so we can share a portion of base with edit access to our clients.
We are thinking of sharing it, if you are interested click here
Hello, we’re interested! We’ve signed up (twice). What’s the next step? :grinning_face_with_big_eyes:
Just my two cents - the reason I ended up here:
For sensitive, critical data, if I want to get someone to help with data entry, I need to be able to give them permission to add records but not to delete anything. I want to be able to have someone create records without being able to accidentally delete or otherwise modify the base/tables.
Editor level permissions minus “delete” would accomplish this.
A write-only permission level would be great too - if I only need them to enter new data, but don’t want them to modify existing data, this would be the better implementation.
We have been using the beta and it is terrific - solves a lot of problems re: user permissions. However, I don’t believe it addresses the ability to only allow users to see selected information. Hopefully that is the next step for Airtable’s development team as it would be very valuable.
How do we get on the beta!!
Just my two cents - the reason I ended up here:
For sensitive, critical data, if I want to get someone to help with data entry, I need to be able to give them permission to add records but not to delete anything. I want to be able to have someone create records without being able to accidentally delete or otherwise modify the base/tables.
Editor level permissions minus “delete” would accomplish this.
A write-only permission level would be great too - if I only need them to enter new data, but don’t want them to modify existing data, this would be the better implementation.
Doesn’t this support already exists through the forms system? I’m not a security expert, but I think a form abstracts data producers away from your base.
How do we get on the beta!!
Hi, just following up about syncing part of your airtable base with clients and partners.
We released the beta version, you can signup there : https://trybases.com
Firstly there is an obvious use-case for a read-only API…
Per-API-key base permissions are on our roadmap, but just wanted to point out that you can already accomplish this by creating a separate Airtable account and giving it read-only access to your base, then using that account’s API key.
Per-API-key base permissions are on our roadmap
Is this still on the roadmap?
Check out this service. https://strictapi.com Looks like they just lunched. They act as proxy between Airtable API and the client. They will create 2 API users for you and each user can have access to different tables.
There’s not a one-size-fits-all solution to user permissions—all of the users who’ve asked us about greater customization in their permissioning have had their own unique workflows and use cases. The challenge for us is to design features that solve the many different types of permission granularity that people want, without adding overwhelming complexity. There are other products that offer highly detailed permissions options, but we don’t necessarily want to bring all of those levels of complexity into Airtable, as we’re generally designed for more lightweight use cases.
We would love to hear more about the specific issues that you’re having with the current permissions model, and what problems you’re trying to solve—the feedback we get from users is one of the most valuable things we can have when we’re trying to design new features to be as elegant as possible.
Can’t believe Airtable can add table and field level permissions, but still allows any user with edit rights (i.e. team member) to see ALL DATA in ALL TABLES. Still makes it useless for me to add team members so must rely on other tools almost solely because of the VIEW ALL strategy employed. Sharing a read-only view in some way does not help.
BTW the simple solution seems to make editable Views sharable to Users and/or Roles. If a field isn’t in the view then the shared user can’t edit. If a Table has no shared views then it is private by nature. Simple, and much needed.
Can’t believe Airtable can add table and field level permissions, but still allows any user with edit rights (i.e. team member) to see ALL DATA in ALL TABLES. Still makes it useless for me to add team members so must rely on other tools almost solely because of the VIEW ALL strategy employed. Sharing a read-only view in some way does not help.
BTW the simple solution seems to make editable Views sharable to Users and/or Roles. If a field isn’t in the view then the shared user can’t edit. If a Table has no shared views then it is private by nature. Simple, and much needed.
The best way that we have of accomplishing this right now is Stacker. It’s actually pretty amazing what they’ve accomplished, because it’s both powerful AND easy to setup. Would be awesome if Airtable bought them and integrated it into the product.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.