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?
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.
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.
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.
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.
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)
@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… :slightly_smiling_face:
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.
