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?
Is there a way to limit access collaborators? I want to see if this product would work for my business, so far it looks great. We have several sales agents and I wanted to see if there is a way to give access to only certain tables within a base? It would be nice to have a table for each agent but limit the access so one agent cannot see the table of another agent. Let me know if this is possible, or the other alternative would be to have all sales in one sheet and limit what each agent can see by different views. Let me know if any of these options are possible.
The only other alternative that may work for our business would be to link between bases, so each agent can have a base, and have one that tracks my inventory. I see that several users have requested this and Airtable is considering it.
It would be very useful to be able to specify a View to enforce when inviting a Collaborator on board. This would afford collaborators a cleaner view of records relevant to them and could also be used as a crude means of row-level security.
At present you facilitate (through the UI) sharing a read-only View and inviting a Collaborator. Essentially I am looking for a conflation of the two. This would likely only make sense when inviting others on board with Edit Only privileges.
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.
In my case at least, I believe that granular (edit,view,hidden) permissions per Column and per Table using the current Collaborator model would suffice.
It appears you already have the infrastructure in place to perform that within the Share View/Base model however the inability to Edit within that model is what ultimately limits the Non-API users.
Having reviewed the API documentation, I’m confident that I could build a web application to perform the functionality however I simply do not have the time to do so. As such I’ve just limited people’s access to View Only and they make email requests to me to update records. Yes it’s archaic but it works and allows me to ensure security and uniformity of the input data.
I would also like to hide some tables and views from certain users. Maybe with an option to exclude people (not breaking the current simple setup). Linked columns could be read only / non-editable or something…
I would like this too. I want to share SOME data from a base, and allow my collaborators to add to and edit it, without giving them access to ALL the data in the base. I cannot figure out any way to do this, as long as Airtable does not support linking between bases.
Yes, I am new to AirTable, and I LOVE it so far. The only issue I am having is that I need the ability to either set someone’s viewing/editing permission on a table level or view level. This way, they can see and edit some of the columns but not certain sensitive ones.
I fully agree. The inability to set specific permissions by views or by columns, or tables is really limiting us from using Airtable more extensively. The use case is HR data where we are trying to be able to link compensation and management appraisal data to employees but want to keep them separate across members in the HR team to have single point accountability. Otherwise we will have difficulties keeping salary information or appraisal information confidential.
