I am very surprised by the omission of this feature, which is a complete show-stopper for using Airtable. Firstly there is an obvious use-case for a read-only API - and since any future enhancement will encompass that, you might as well get on and do it. Like yesterday. The other big use case is for an API that acts like a collaborator. So being able to create a ‘dummy’ collaborator and then operate the API with the permissions of that collaborator is extremely simple to explain, simple to manage, requires very very little extra UI, and does everything.
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.
Agree on all of these. The locking columns would be so amazing. We really love Airtable but dislike it’s all or nothing. If someone has read access they can only see the main view as it’s currently filtered. When someone has edit they can edit anything and everything and then creator is barely a step above that. There’s no middle ground for restrictive access. Also, when discussing moving towards paid versions, we’d love a client to have access to on column only to update but it doesn’t make sense for us to pay for them for a whole year when they’ll only need access for one event, and we don’t want them to have edit access, only edit on one column. Lots of opportunities for improvement on the access levels here.
Thanks for flagging that up - that seems like a decent workaround.
This is the solution we all need. Have permissions for views (this solves table and field dilemmas)
I love airtable on a personal level, but I can’t convince my company to adopt it yet because there are minimal permission options.
Here is my use case:
We are currently using Asana for this, but I think with permissions, AirTable would be better. We have three main teams that use Asana to track issues: Sales, Service, and Production. Each team uses Asana to track problems they see in the field or things they need fixed/updated (think tech/marketing/service issues). Every week we have an in-house production meeting, where we go through all production issues from sales, service, and production. Right now each team has their own board where they can post requests and other issues, and the cards that pertain to multiple people are added to the correct corresponding boards in other departments. While this works fine for now, it doesn’t have the search and sort functionality that I need. Airtable would allow me to re-order everything by different parameters which would help our team better identify priority issues. Our problem lies in that the three different groups don’t need to see everything on each others tables, just the entries that pertain to them. They all also need to be able to edit and comment on things shared with them.
We have many other uses for airtable as well, but until I can get more permissions, it will not meet our needs, but it is so close!
I love the iCal subscription link which enables me to share each band member’s tailored gig calendar for all appearances where they are named in the personnel column. I would really like to be able to limit their viewing permissions, tho, to specific fields (venue, address, sound check time, lodging, etc.) Instead they can click thru and see all fields - including the more sensitive money info.
For me I’d be thrilled if each calendar view could have a “hidden fields” feature like other views have.
Or, another solution would be to have some “private” fields that are viewable only by Creator-level or Edit-level users (NOT by anyone with an iCal subscription link.)
Thanks for working on this! It seems like lots of folks are chomping at the bit for a similar feature.
Long live Airtable!
Hey there @Ruth_Merenda, I’m running a band too and would love to ask how to get that iCal subscription happening… is it easy to setup? I have looked (even in the Blocks thing I’m beta-testing for Airtable) and can’t find it!
Looks like there’s a lot of consensus here on how the permissions could be set up to meet nearly all use cases, and Google Sheets & Smartsheets both have working examples that would be a great start (a million times better than nothing at all).
I work in the office for a construction company and I’m checking out Airtable. I’m very close to getting tables set up so that we can use Airtable as our one, master system. Not having any fine-tuning for permissions may end up being a dealbreaker for us.
- I’d like to give foremen the ability to checkmark a job complete, add remarks into a notes box, and upload photos, but I don’t want to give them blanket permissions and them accidentally delete or edit a table, record, etc.
- The “old guard” here in construction is definitely not computer-savvy, so in addition to permissions control, only letting them see the 1 specific view they’ll use is very useful. One wrong click into another table/view and they’ll be lost.
- A big concern with estimators/salesmen is that they don’t want their customer info out there for other estimators to try to steal.
- Some of the formulas, rollups, and records would definitely need to be lockable, especially ones regarding money. Again, to help prevent someone mistakenly editing/deleting something. Imagine someone accidentally deleting a record for a six-figure project and it not getting billed.
Would love to move our spreadsheets to airtable, but need granular permissions, is it possible to have 1 large table with multiple users being able to access it.
Depending upon what we setup id like for instance : a table with 26 columns. Admin users would have read / write access to all 26 columns. Manager users would have read write access to the first 20 columns, and read only to the last 6. Staff users would be able to read / write the first 10 columns, read only the next 5, but not be able to see any others.
Is that possible ?
I would also love to see more granular permissions. Here’s our use case:
- Inventory of department systems and data
- Edits should be made by specific named users that are assigned by a super admin.
- Those users can only edit records in their department, but they can view all other records
- Those users cannot remove any records
- Instead, they flag records for removal and an admin with delete control will take action to remove the record if approved
We can get some of this functionality in Airtable, but we need a user type that has create and update permissions, but does not have delete permissions to begin chipping away at this use case. Delegating users doesn’t make much sense right now without us being able to control deletes. This is for reasons of governance and audits.
Recently I started freelancing with an ad agency.
I noticed they were using the separate tools that would be better if combined into one Airtable base.
I got excited about recommending Airtable. Could I notch a win with this company by showing how they could save money an and time with Airtable.
Nope, I can’t. Granular permissions are important for this company. They use many freelancers and each one has a set of things they can do and see
@Hashim_Warren - That’s funny! Coincidentally, I had exactly the same experience with a content marketing group on Thursday! I actually built a demo base for them and did a one-hour presentation, but in the end, I can see that it will not work because of the number of freelancers they need to “partially” involve. Exactly the same issue!
I have a hunch that the barrier is philosophical not technical.
- Airtable isn’t going after the Fortune 500. They want the Fortune 50 million. Businesses and use cases that are too small for anyone to really build a packaged database for.
That’s the fashion blogger keeping track of her sponsors and editorial calendar. That’s the family owned bodega keeping track of their inventory and suppliers.
- That means Airtable is competing against Microsoft Excel and Google Sheets. Permission management isn’t what made both of those products so popular.
Airtable works for me because my co-workers actually use it. That’s a big difference with other products we tried.
So isn’t that crazy? I want more permissions to lock people out, but if it weren’t for the easy onboarding and adoption, Airtable would have failed at my last company.
I hope they figure out how to cut this knot.
I want to +1 this yet again. And I’ll keep requesting it until we get some sort of more granular control. Nothing too crazy, but it sure would be nice to at least specify specific tables as read only for specific User Types.
I’m doing annual clean-up on our main CRM & Sales base. Luckily I’ve got excellent employees so things haven’t gotten too messy, but there are inevitably erroneous records accidentally created… and every year (or whatever time period) this requires manual clean up.
So please, make 2018 awesome for those of us who care enough to post here (and the many more who could use it but can’t be bothered to post) and add a new User Type. Something with more permissions than Read Only but less than Editor. Thanks!
+1 to being able to lock table(s) in a base. Some tables should be view only and some should be editable.
We have some major product improvements around fulfilling enterprise needs and will be introducing features like more granular permissioning.
Very good news and a smart move. This will dramatically expand the use cases for Airtable…
+1 Yes fellow humans, locking tables and being able to hide them would be a “fix” for not being able to link bases. I want my team to be able to work on a single table and pull info from other tables that are managed by other teams. Being able to lock a row of data would also be beneficial. For those teams like ours that are using this as a real database that is flexible, a couple of things like this are really massive pieces of the puzzle.
The issue I’m grappling with is storing social security numbers for a use case in the legal space. I think we can be very open with access in the system we’re looking to build, in a lot of ways, but not sure we’ll want to work with AirTable if everyone who’s going to have access to the system, will have access to view SSNs.
Per-view permissions could do it: we could just grant editor permissions on a set of views, none of which had SSN.
Per-table permissions would be even better: we could just create a single table with sensitive info, that’s 1-1 with the table it’s related to, and then we could grant collaborator access to everything but that table.
Some kind of cross-base linking functionality could also do it: we certainly could go to considerable effort to hack things together. For example, if there were ways to include a link to a record from another base, even if most things that involved it required some extra coding, or there were somewhat limited uses, we could have another base with the sensitive info, that some people couldn’t access. When non-privileged users tried to edit or view that info, as long as it failed fairly gracefully, e.g. showing the value as “you don’t have access” or “error” but having the rest of the view still work, that’d be fine.
Per-record access might work: we might be able to hack something together.
I also think about 90% of the comments on this page could be addressed with either per-table or per-view access, for users willing to make it work. I guess the crux of the issue is that in the current model viewing data is considered the least sensitive thing, whereas sometimes editing, or even changing database structures is way less sensitive than viewing key fields.