I have a hunch that the barrier is philosophical not technical.

1. 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.

2. 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.

Fingers crossed…

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…

As a workspace owner, I would like to restrict access to specific tabs based on user role so that I can protect sensitive information without having to create a separate base.

This is going to be needed for many serious business use cases.

We’d find this helpful too. We have different tables for different teams of users, all of whom need to link to other tables, but they don’t need to be able to edit records in the tables they’re linking to.

+1 on this

So many of the best things about Airtable is only possible when you keep all in the same table, but there are several downsides to everyone accessing everything

+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.

Exciting stuff! Are there any plans to introduce more granular permissions by table, not just the entire base? For instance I’d love to be able to share only certain tables/views of a base with users, but not give them access to the entire base. Without a feature like this, all users have access to all information within the base, which makes it difficult to fully implement in our organization.

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.

I posted my concern about the security implications before seeing your discussion (see here:

My post).

I can see I am not the only one with these concerns. Airtable, are there any updates on introducing

more granular permissions?

@Katherine_Duh @Howie

After reading so many posts on this very important issue of granular permissions,

can you please let us know when you are going to introduce them into Airtable?

This part clearly hampers a wider use of your product which is a good one but

certainly needs this massive improvement. It would be reassuring if you could

let us know if and when you are going to implement this.

Thank you.

+1!

We really do not have enough opportunity to share a part of the table with access for editing or commenting.

Need more opportunities for sharing tables!

My organisation want to completely switch from Google tables to your service, but the lack of this capability limits us.

Yes please. as you can’t sync between bases or teams then the ability to hide my sales table to some of the staff is null. left with having to manually sync between two bases on different teams.

As requested, here is my use case.

I use freelancers to work on projects for me. I want them to be able to mark off tasks as done, but I don’t want them to see all tasks. I want them to only see their own tasks.

I can create a view that only shows them their tasks, but if they are a collaborator, they can still change this to see all tasks.

@Airtable_Team, @Howie, @Katherine_Duh

You guys should see this kind of situation as a potential for user-base growth. If @Garland_Coulson invites a freelancer to collaborate on his base for a period of time, and that freelancer has not seen Airtable before, he has now not only been exposed to your service, but actually used it in an already functional base - he has seen what it can do, how user-friendly it is, how beautiful it is to behold when he compares it to his Google Sheet that has grown unwieldy with time. When @Garland_Coulson boots the freelancer from his base at the end of a project, said freelancer finds himself missing Airtable’s lovely interface and powerful entity relationships, and decides he’s going use that account he already had to make in order to take a job with @Garland_Coulson and make his own bases in it, moving his own workflow into Airtable… and sooner or later, Airtable rules the world! (ok, a step to far)

– I’m inserting this after having written the rest of the post to make it clear up front that this is not an angry post - only a plea in the cause of this #feature-requests –

Different use-cases aside, I think there’s a pretty clear argument to be made that extending user-permissions to the level of a Table and a View is a win-win-win. There are just so many use-cases that could make use of one or other of these collaboration levels that it seems an inevitable necessity for you guys to implement.

And when it comes to billing, you could justify charging the same for a collaborator at any level - you already do that with Workspace vs Base collaborators at any permission level, and while there may be some complaining on the forums about that, most of us are fine with it and pay what you ask, because we recognize that this is quality software, and the service is worth the cost to us.

You’re concerned about ease of use and UI/UX clarity, and rightfully so - but I don’t think this represents a major challenge to that. I think users will understand the options here:

Do you want to invite this person to collaborate on -

• The Workspace?


• The Base?


• The Table?


• The View?

So I guess the biggest question becomes, is this possible with your current software structure?

It seems like it should be, given that every element within Airtable - with the exception of a Field and a Cell - has a unique URL associated with it. And you’ve figured out a way to hide fields from “Shared Views” that we do not want viewers to see, so it seems you should be able to do the same with, for example, expanded records in a view where the collaborator expanding the record only has permission to see that view - she/he cannot unhide hidden fields or group by hidden fields, only reorder/sort what they have permission to see, and add/update the records they can see.

There are some challenges that @Katherine_Duh has brought up in other areas of the forum pertaining to how to deal with the display of linked records, for example - and those are valid challenges. But I am paying monthly for your SaaS so that you will continue to overcome those challenges.

I’m sure you can see the details of my account, so you know that I have 6 workspaces with 65 bases across them. A few of my bases have collaborators, but the majority of them don’t. And the #1 reason for that is the lack of granular user permissions. I do a lot of data entry that could (really should) be done by other people in my company to free up my time to focus on - perk up your ears - moving MORE of our workflows into Airtable and bringing you more paid users. The reason I can’t do this is because I can’t afford to have a base entirely exposed to any one of my data entry co-workers, for various reasons that span the gamut of reasons for why you wouldn’t want a user to have access to certain portions of a database.

I think you guys have done a fantastic job with the collaboration and permissions that you have implemented so far, but I think you are alienating large groups of users by not making this #feature-requests a priority, and thus leaving money on the table.

Please work on:

• Collaborators at the Table Level


• Collaborators at the View Level

As a followup to @Jeremy_Oglesby comment, I am a professional speaker who reaches thousands of people a year with my workshops, online courses and webinars.

I regularly recommend my favorite tools to my followers and I have brought a fair number of people to Airtable already.

I know the usually assumption is that you have a team of people that stays fairly static but more and more people work with a wide range of freelancers.

Over a 1 year period, I will use different freelancers for:

• virtual assistants (probably 3-6 over a year)


• web design


• graphic design


• copywriting


• content writing


• keyword researcher


• SEO consultants

Already nearly at 10 people I might use, all with their own tasks. I only want myself (or maybe a manager I hire) to see all the tasks.

In addition, I use Airtable to gather potential webinar instructors and run joint webinar events with them. I want to give them tasks/checklists for the event. I could have hundreds of instructors eventually.

Not only is the issue of each collaborator seeing all the tasks a problem, this is also a problem for Airtable pricing.

If I have 10-20 freelancers and 100 instructors I am working with, there is NO hope of staying upgraded to pro pricing. $24/month x 120 = $2,880 per MONTH.

I am an entrepreneur working from my home office. I do make my full time living online but there is no way I can justify $2,880 a month for Airtable. So none of the premium features can be available to me.

Just wanted to provide some perspective on how important it is to be able to provide “by view” collaborators who can’t see the rest and to give some thought to how pricing can work for small business owners.

Hi, just adding my +1 on this. I work with a lot of freelancers, too, and need to segment permissions (if it’s not possible to link between bases). For airtable to work for us long-term, we need to be able to share single views or individual tables.

Is this on the roadmap? If so, what’s the status? Is there a beta in the works?

Thanks- keep up the good work!

+1 on this, we have to be able to lock columns to avoid record deletions - even a prompt when about to delete a record would be helpful. We are using in a manufacturing setting where we need to keep people from accessing views that are unrelated to their workspace, and limit them to only simple inputs.

+1

Please add this.

Thanks

+1

My use case:

The first app I want to build is for project and task management.

The ideal scenario, for my users, is the ability to create tasks and projects privately, publicly, for selected users and (ideally, but not critically) user groups - and change those audiences as required on a task-by-task and project-by-project basis.

Row-level user permissioning would be very helpful.

+1 for more granular permissions. even if it’s months away, some sort of guidance on timing would be hugely helpful! thank you.

@Howie_Liu

You’ve created a great product. This is the biggest road block I can see which is a matter of data security.

We’re looking for collaborator level permissions so you can set views for specific collaborators. E.g. I create the Howie view, and only you can see, edit, modify the data in that view.

A workaround could have been to use web views but these are read only.

The case study here is an organisation with all their order data in Airtable.

Different teams work on different parts of the order (like an assembly line). Each team only needs to see their view and data they need to input to help complete the order. They don’t want or need access to the entire base with all the views. This seems to me like it would be a common requirement when thinking about how organisations work in teams with shared data.