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 9 / 11
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.
Please create granular permissions that provide the following functionality:
Permissions can be granted/removed by: Table, View, Field, and record
Access to VIEW can be granted or removed separately from edit access.
Permission profiles can be customized and collaborators be assigned to a profile giving a range of users the same permissions. Additionally, it would be great to then be able to edit the individuals permissions after assigning the permission profile (essentially using the permission profile as a template).
We are grateful for the efforts to implement permissions, but those recently implemented mostly just protect against someone editing data on accident or maliciously. The functionality of Airtable was not expanded significantly. The added security is nice, but not game changing.
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.
Hey! Your app looks really interesting!
Hey! Your app looks really interesting!
Stacker is not my app! But it is an awesome product.
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?
Hi @Katherine_Duh!
What industry do you work in? What role do you have? How are you using Airtable?
I work for a creative agency, and we are currently using Airtables to track project, daily assignments, and more recently now an hours logs and expenses that are connects to each project.
Are you most concerned with view access, write access, share access, or another form of information access?
Currently we are tackling an issue where we would need to restrict view access from certain tables or columns.
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?
We are currently using it our team members that are workspace collaborators.
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?
Currently I have a staff table that has salary information that shouldn’t be viewed by other members of the team. This is linked to an hours log where they track all of their hours for the day. One of the fields would be a formula calculation based on what they are paid and how many they spent working on a task. They also are inputting a project (that is linked to another table) that the task is associated with and that all gets rolled up into a project view that has labor costs, expenses, profit margin, and budgets tied to it. End result is to see a real time project overview and where its at vs the budget.
Do you use linked records at all? If so, how would you expect that linked records would interact with more granular permissions?
We do use linked records. We use them for a client list, which then those are linked to specific projects. The expenses table and hours table are linked to the projects table.
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?
Katherine,
I have an example as follows: Staff Data
The purpose is to have one centralised repository for staff data.
There are read only views for typical contact data, profile pics etc. that every member of staff may want.
Administrators are responsible for induction / onboarding so need editor access, and ideally creator so that they can add fields etc, change views.
This is great at a simple level - most roles can have access to view data, but there seems to be no way to restrict access to sensitive payroll data (that I want to put in a separate table). I cannot see any way to restrict access to users like the administrators who need edit permissions from being able to see payroll data, that we don’t want them to see…
The only solutions I can see are convoluted workarounds, with multiple bases and copying data between them.
It would be great if you could resolve this.
Thanks Gary
Hey everyone!
Just wanted to confirm if this record level security feature is possible in Airtable:
The ability to limit specific records or rows to authorized users. Meaning the non-owner/creator user who is accessing the table will only be able to view those records attributed to them.
Example: Kelly Smith will only be able to view sales records that she herself closed. When Tom Jones logs in, he won’t be able to see any sales data attributed to Kelly Smith.
Thanks!
John
Hi all,
I read this conversation and am looking for a way to restrict access to airtable when using it with REST API. I use airtable in 2 mobile apps (iOS and Android) with an API key. There is a chance that somebody steals the key from the app. Actually with an API key this person would have full access to every part of the database. I would like to know if I can restrict it and switch between the following two possibilities:
a) full access from webbrowser/airtable app, but “read only” when using REST API
b) full access even from REST API (API key)
Greetings, any help would be appreciated.
Hi all,
I read this conversation and am looking for a way to restrict access to airtable when using it with REST API. I use airtable in 2 mobile apps (iOS and Android) with an API key. There is a chance that somebody steals the key from the app. Actually with an API key this person would have full access to every part of the database. I would like to know if I can restrict it and switch between the following two possibilities:
a) full access from webbrowser/airtable app, but “read only” when using REST API
b) full access even from REST API (API key)
Greetings, any help would be appreciated.
@Michael_Rogulla I think the only solution right now is to “proxy” your Airtable requests through a backend that has access to your API key.
This is simple to achieve with a cloud function. If you use a third party service like Netlify, they let you invoke 125,000 serverless functions per month (hosted by them for you on AWS Lambda) on their free plan, which doesn’t require a credit card.
Then, once you have that “middleware”, you can consider doing fancier things like caching your Airtable data do you don’t hit the 5 requests per second limit. Or restricting access to specific users depending on their role (admin, etc).
Another advantage of keeping your API key out of your app is that you can immediately change it if it is compromised. Netlify, for example, will let you add it as an environment variable in their dashboard so that you can keep it out of your Git repository.
Other than Netlify, you can try AWS directly, or Azure, IBM Cloud, Google Cloud, Cloudflare Workers, etc. Most offer a free tier in addition to more flexible credits for new account holders. And you don’t have to write it in JavaScript. I think Cloudflare treat Swift as a first-class language citizen.
Hi @Stephen_Cremin, thank you for this helpful tip. I’ll check out if I can use a database proxy with my app. I develop my apps with “Thunkable” (https://thunkable.com/#/), do you have any experience if they are able to use this technique? It would be a great solution for the “5 requests / sec” limit!
BTW: I’ll question the same to thunkable’s support… 
Hi @Stephen_Cremin, thank you for this helpful tip. I’ll check out if I can use a database proxy with my app. I develop my apps with “Thunkable” (https://thunkable.com/#/), do you have any experience if they are able to use this technique? It would be a great solution for the “5 requests / sec” limit!
BTW: I’ll question the same to thunkable’s support…
Looking at the Thunkable docs, in addition to the built-in Airtable data access, you can use Web APIs directly.
Use that to talk to your serverless function.
The Airtable API itself is very flexible. The only tricky part is batching requests when you need more than 100 rows in a table, and you may with to handle that in your app.
If you do opt for Netlify functions, I remember they have at least one sample project with published code that shows you how to proxy through to Airtable.
Maybe we’re both being overly paranoid about the risk of the API key leaking. I’d be interested in hearing what others think.
Personally I would want my own “middleware” in place for additional functionality including rate limiting, monitoring, caching, abuse prevention, etc.
I looks like a big solution to a smaller problem. My main goal is to prevent users from changing my data. That said I can take API key leaking, if it would be possible to set a base to “read only”. Right now this seems not to be the case, so the proxy is a plus for security.
On the other hand I do not know if thunkable uses internally also the REST API. Because it is a no-code platform I use blocks but do not know what’s behind the curtains. When using the Web APIs I am aware of the 5 requests/second limit, but I don’t know if this limit may apply also to the internal functions (blocks). This is a reason for me to have a closer look at caching proxies, not for security but for availability reasons.
Hi all,
I read this conversation and am looking for a way to restrict access to airtable when using it with REST API. I use airtable in 2 mobile apps (iOS and Android) with an API key. There is a chance that somebody steals the key from the app. Actually with an API key this person would have full access to every part of the database. I would like to know if I can restrict it and switch between the following two possibilities:
a) full access from webbrowser/airtable app, but “read only” when using REST API
b) full access even from REST API (API key)
Greetings, any help would be appreciated.
Anyone who discovers you API key has access to not only every part of you base, but also every part of every base in your entire account.
Another option for “read-only” access is to create a new Airtable account and give that account read-only access to only that specific base. Then use that user’s API key to access the Rest API from your app. If that API key is compromised, no data can be changed and no other bases are compromised. Read only users are free.
For full access via the Rest API, I also recommend a proxy to store the key. That will allow you to change the api key if you ever need to.
Anyone who discovers you API key has access to not only every part of you base, but also every part of every base in your entire account.
Another option for “read-only” access is to create a new Airtable account and give that account read-only access to only that specific base. Then use that user’s API key to access the Rest API from your app. If that API key is compromised, no data can be changed and no other bases are compromised. Read only users are free.
For full access via the Rest API, I also recommend a proxy to store the key. That will allow you to change the api key if you ever need to.
Hi @kuovonne, that sounds like a great idea. I am on the free plan, how can I create a new account? I entered “create new account” in airtable’s help pages, but got no result that helped me further.
Hi @kuovonne, that sounds like a great idea. I am on the free plan, how can I create a new account? I entered “create new account” in airtable’s help pages, but got no result that helped me further.
You will need a different email address for the new account. After you setup the new email address, add that email address as a base collaborator then follow the instructions in the email that is sent. (You may need to log out of your existing account first.)
Airtable is a wonderful platform but it moves SLOW. Like, glacially slow. I wanted to move my company to working with it but I when I saw that there are so many requests that were addressed in a very knowledgable and lengthy ways by the company’s representatives it seems like most of then got stuck in this phase. Of writing essays.
This request is more than 4 years old. 4 years. And how much changed with the user permissions? NOTHING.
I love the new automations and the button field which is really awesome but without the ability to control who can see and edit what it is useless.
Get it together Airtable. User permissions are not that hard. Give your customers clarity. They deserve it. And please, stop with the essays. Learn to write concisely - it is frustrating to read so much just to acknowledge that you will do nothing about it.
To sum up… Find a way to move faster in crucial features or Monday will eat you up.
Airtable is a wonderful platform but it moves SLOW. Like, glacially slow. I wanted to move my company to working with it but I when I saw that there are so many requests that were addressed in a very knowledgable and lengthy ways by the company’s representatives it seems like most of then got stuck in this phase. Of writing essays.
This request is more than 4 years old. 4 years. And how much changed with the user permissions? NOTHING.
I love the new automations and the button field which is really awesome but without the ability to control who can see and edit what it is useless.
Get it together Airtable. User permissions are not that hard. Give your customers clarity. They deserve it. And please, stop with the essays. Learn to write concisely - it is frustrating to read so much just to acknowledge that you will do nothing about it.
To sum up… Find a way to move faster in crucial features or Monday will eat you up.
Welcome to the Airtable community! @Oren_Menashe
I’m not sure which “essays” by company representatives you are referring to. Almost all of the posts in this thread and in the community at large are written by other Airtable users on their own time, not Airtable employees.
Although Airtable does not yet have the advanced user permissions that you and many others would like, I wouldn’t say that Airtable has done nothing in four years. Airtable has released table and field level permissions. Airtable allows shared views and protecting shared views via password or domain. Airtable also just release syncing between bases, which has huge implications for based design and user permissions.
Thank you for your reply kuovonne.
My apologies. I wasn’t aware of that. These are great improvements.
The view permissions for a specific field is crucial to our work. Do you have it on your roadmap? And if so, when should it be released?
If you’re looking for an example for a lengthy essay, just look at the “Solved” post at the top of this page.
The “Solved” tag is far from the truth.
Anyway, thanks again and keep up the good work!
Thank you for your reply kuovonne.
My apologies. I wasn’t aware of that. These are great improvements.
The view permissions for a specific field is crucial to our work. Do you have it on your roadmap? And if so, when should it be released?
If you’re looking for an example for a lengthy essay, just look at the “Solved” post at the top of this page.
The “Solved” tag is far from the truth.
Anyway, thanks again and keep up the good work!
@Oren_Menashe
I do not work for Airtable and Airtable tends to keep quiet about its roadmap. I have no more idea of when view permissions will be released than you.
If you need users to be able to edit a record but not view a specific field in the record, I suggest you check out the third party tools Stacker and/or MiniExtensions.
Thank you for your reply kuovonne.
My apologies. I wasn’t aware of that. These are great improvements.
The view permissions for a specific field is crucial to our work. Do you have it on your roadmap? And if so, when should it be released?
If you’re looking for an example for a lengthy essay, just look at the “Solved” post at the top of this page.
The “Solved” tag is far from the truth.
Anyway, thanks again and keep up the good work!
Oren, in all forms of technology, pointing to a forum thread that’s nearly four years old is pretty much irrelevant. A lot was said back then that is certainly untruthful today. We know more about workarounds, and we have vastly different features that we can draw upon.
Whenever looking for answers in a technical climate, it’s best to start reading from the bottom because that’s where the most recent and accurate information will be. Blogs, for example are reverse chronological because the pace of change, knowledge, and understanding makes earlier posts obsolete.
The concept of “user permissions” and “view permissions” are very different ideas that need finer points, but regardless, Airtable is probably not the right platform if this feature is crucial to your work because I don’t see it happening soon. Best to move to something that handles these use cases
.
Perhaps, but I think you actually mean field-level user permissions. If so, this statement could could not be further from the truth. I would love to learn how you conclude that field-level security and permissions are akin to “easy”. Please feel free to write a lengthy essay so that I and the Airtable dev team can understand the secret to effortless field-level permissions design.
Thank you for your reply kuovonne.
My apologies. I wasn’t aware of that. These are great improvements.
The view permissions for a specific field is crucial to our work. Do you have it on your roadmap? And if so, when should it be released?
If you’re looking for an example for a lengthy essay, just look at the “Solved” post at the top of this page.
The “Solved” tag is far from the truth.
Anyway, thanks again and keep up the good work!
Another alternative involves updating records through forms and automations. You can create a button that opens an update record form targeting the record of choice. Then use automations to take the input from that form and update the record.
It’s more work than the three sentences above may make it sound, but it allows you to give a view-only link to someone and restrict exactly what they can see and edit.
Also, don’t take Bill’s attitude too personally. Although he is right, the sarcasm at the end of the post might be a bit much
Another alternative involves updating records through forms and automations. You can create a button that opens an update record form targeting the record of choice. Then use automations to take the input from that form and update the record.
It’s more work than the three sentences above may make it sound, but it allows you to give a view-only link to someone and restrict exactly what they can see and edit.
Also, don’t take Bill’s attitude too personally. Although he is right, the sarcasm at the end of the post might be a bit much
Yes, there’s always an edginess when digging for clear requirements and I am known for being a little blunt. :winking_face: However, I wasn’t attempting sarcasm in this case - I was simply recognizing that Orem had reflected on and complained about the earlier comments that were unhelpful and invited him to provide some thoughts that are detailed and contained substance.
Is it possible to do collaborator-field based dynamic permission? i.e. to let only assigned collaborator to see or edit the line.
Is it possible to do collaborator-field based dynamic permission? i.e. to let only assigned collaborator to see or edit the line.
Nope, you can’t do that @Ohad_Shavit
Thanks Jarvis. Is there any alternative?
In Airtable, you can probably use a workaround that uses Airtable sync. It might take a few trial-and-errors to get it working the way you like, but it’s the cheaper route: Re-Linking data or two way sync?
The more expensive but hassle-free route would be to use https://stacker.app/ (so far this is the only 3rd party utility which allows you to do what you’re looking for in the most plug-and-play way)
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.