Giving read-write access to select records in a base to select users

3486 16
Showing results for 
Search instead for 
Did you mean: 
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi All,

I have a base that represents validation tests. Let’s say I have a total of 30 records. 10 records need to be updated by Vendor 1, the next 10 by Vendor 2, and all 30 need to be updated by Employees.

Airtable does not support record level permissions at this time.

Am looking for solutions to accomplish this.

A potential solution: create a Master base with the 30 validation tests. Programmatically create a base per vendor and copy records from Master to Vendor base. When vendor updates the records in the Vendor base, copy the updated records to the Master base. Is this doable?

Is there something easier?


16 Replies 16

That Share link takes me to a screen that allows to me to add collaborators to the workspace but not specifically to the base itself. Do you see something different?

Or am I misunderstanding what I’m looking at? (That’s possible.)

@Chris_Parker - I hope I’m not wrong about this, but I very well could be.

When I create a share, I do so in the context of a base - the dialog and the selector is integral with the base icon. As such, I expect (and always have expected) that the sharing action is designated to the base (and only the base) for which I intended to expose access.

Given that the Share option is available on each base (and inside the base display), it was always my assumption that this share feature is specifically associated with the base, not the workspace.


Separately, there is a Share feature at the workspace level too. I think you are conflating these two very different sharing options. But I’m still new at this.


If this is not the case, three things come to mind:

  1. I am an idiot (and this may not be the only indicator of this ;-).
  2. If true, the Airtable security model is really misleading.
  3. If true, the Airtable security model makes it wholly unusable for most businesses and use cases.

I believe you are giving access to all bases in the workspace.

A workspace collaborator has access to all of the bases in a workspace (at a specified permission level).

Correct. When - and only when - you use the Share option at the Workspace level.

Here’s a workspace (personal) where I shared a single base to my self from my corporate account (which has 75 bases) -


There is only one shared base in my personal account despite there being 74 other (unshared) bases in my corporate account.

You’re rocking my world, Bill. Thanks for clearing this up for me! I think Airtable’s verbiage leaves a lot to be desired on those share screens. Specifically, the one where you share from the Base itself.

This brings up a question which is, since I’ve been sharing at the workspace level, do I have to remove existing collaborators and then share again from the base or can I adjust it in-place?

I’m not entirely certain of the right way to unwind this, but here’s my assessment:

If you try to adjust the security scope for each of the bases, thus eliminating access from certain users, you risk the possibility that any new bases will be shared under the Workspace scope. This would not be good as it essentially makes every new base “public” to all workspace users without any warning.

Better to eliminate all workspace grants and reapply access control by base. Yeah - it’s a bunch more work, but you don’t want to have this conversation with your boss.

Yeah, I agree. Fortunately, however, it’s not a severe situation like that but it’s better to clean it up now than later.

Where this is really going to be helpful is that I have been planning to make a new workspace because I really do need to keep a new base private and I thought I was going to have to pay twice for myself: once in my original workspace and once in the new one.

This makes for some good news overall.