Skip to main content

Earlier today I responded to a question from a new user here, explaining how she could hide a field on a locked view and keep the field hidden from non-creator users by making it visible only on a personal view configured by the creator. I then had to add that this is security theater (I think that’s the phrase we use these days) because in truth, any user with editor or commenter privileges can simply duplicate the locked view as a new personal view, which they can then configure to their heart’s content–including making visible the fields that the base creator wanted hidden.


After posting my response, I began to feel uneasy, so I looked into this a little more deeply than I have before, and I’m a bit disappointed by what I’ve found. I’m praying someone here tells me that I didn’t look deep enough–that there are better answers to my concerns. But at the moment it appears that base creators have only a very limited, casual sort of control over who gets into their bases.


.


Nightmares


Consider this scenario. I develop a base for a law firm. I’m the creator, my contact at the law firm is the Owner, and the half dozen users in the firm are editors, because, well, because they need to be able to edit the data in the base. And let’s say that the base contains info that the law firm regards as sensitive: perhaps info about their clients, or data for a lawsuit they are working on; etc.


Now, one of the employees at the law firm is let go. Naturally, the firm’s manager (the base Owner) emails me and I remove that person’s sharing privileges. But the person calls somebody still working at the office and that person (whether maliciously or stupidly) shares the base with the ex-employee. The ex-employee is back in, thanks to a decision by somebody who perhaps should not have the authority to make that decision.


Or somebody on the other side of the lawsuit sweet talks one of the firm’s employees and they agree (again, doesn’t matter whether this is malice or mistake) to share the base with somebody who shouldn’t be allowed to view what’s in the base at all. And if these security breaches are committed by somebody with editor privileges, the person who should not have access but now does will actually be able to do things like edit records, delete records, etc.


I use the example of a law firm because most of my development work has been for law firms. But I don’t think I’ve ever developed a base for any client where the client didn’t care about controlling access.


And what if the security breach is committed by somebody with only read-only privileges? Well, even somebody with read-only privileges has the ability to share the base. Okay, fine, maybe I’m willing to live with that. The problem is, if I’m not happy about that, even as base creator there’s not a thing I can do about it.


Wow, just wow.


.


Living in the real world


Now systems like FileMaker, AppMaker, Caspio, Servoy and nearly all SQL app front ends, give developers the ability to restrict access to the databases to specific users and only those users. (I don’t understand the security models for Coda or SmartSheet well enough to comment on them.) If developers wish to authorize admin users to control access, too, they can do that. But who gets into the solution is always restricted to somebody who is, in theory at least, a responsible user. With Airtable on the other hand, granting access to the base is the prerogative of any and all users, regardless of their privileges.


Of course, I’m aware that users are always the biggest weakness in any security system. There’s always the chance that an authorized user might share his or her credentials with somebody who’s NOT supposed to have access. But doing so would be hard to do by accident. In those other systems there’s no “Share” button that invites the user to give some stranger access to the base. Since my users all log in using their email addresses, anybody who logs in using somebody else’s email address will be aware that they’re doing something fraudulent (even if they don’t realize how serious it could be). And in at least some of those systems, it’s possible to do various other things to minimize the risk of unauthorized access: require two-factor authentication to an authorized user’s mobile phone or email perhaps; and/or track IP address from which user is connecting and even restrict users on that basis.


.


My three wishes


I know that Airtable is designed to be like the friendly and convenient corner store, not like an Amazon.com distribution center that uses metal detectors and employs armed security guards. I love that about Airtable.


Still, at a minimum, I wish that any (or all) of the following were possible:



  • Creator should have option to hide the share button for all non-creator users

  • If creators aren’t given ability to decide who can share/not share the base, then read-only users absolutely should NOT have this ability. When I think “read only” I don’t think “read and make a copy for all your friends”.

  • Finally, there should be a privileges level just below Editors called perhaps “End Users”. End Users should be allowed to edit data in records but NOT edit locked views, that is, for End Users, the “create private view” button would disappear.


I gather that some greater degree of control MIGHT be achievable if I gave access to bases strictly on a view-by-view basis using links that are embedded in a web page, but for me, that dramatically limits Airtable’s appeal and potential usefulness.


Somebody is going to read this and think, “My my, he’s not a very trusting person!” Guilty as charged, your honor.


Please tell me what I’m missing!


William


Thanks for mentioning the enterprise admin panel. I hadn’t seen that and have never investigated the enterprise account. Will try to find time to do so in the coming week. I am working in Pro account and have started all my tests in my pro account (then sharing to free accounts I have at different email addresses). So the weaknesses that I have described are there in the pro accounts as well as free accounts.


But I’m an independent developer. My clients (mostly but not exclusively law firms) have between five and almost 100 users. But they all have the same security needs. Will have to figure out if there’s a way to make an enterprise account work for my needs. One of Airtable’s major advantages for my clients is that there’s a free account level for occasional users, of which I have many.


I’m hoping that Airtable will very soon release an upgrade that has sharing restrictions similar to those found in Google Sheets or Coda.


Thanks,


William



It sounds increasingly like you need Stacker.


2025 Update:

This is an outdated thread, so the information presented above is no longer accurate.

  • Since 2021, Airtable’s interfaces were specifically designed to solve this problem. No users need to be granted full access to the base anymore. 
  • Since July 2024, Airtable’s interfaces have been able to be shared publicly in a read-only state.
  • Since March 2025, Airtable’s portals feature has allowed interfaces to become a customer portal, so external users can view and edit their own records.
  • There are also 3rd-party customer portals that communicate with Airtable, such as NolocoJetAdminSoftrPory, and Glide. (I gave an entire one-hour webinar on Noloco called Building a Client Portal on Noloco powered by Airtable.)
  • External read-only users can edit your Airtable records for free by using Fillout’s advanced forms for Airtable, which allows users to update Airtable records with a form. (I demonstrate how to do this in this Airtable podcast episode.)
  • External read-only users can also edit your Airtable records for free by triggering a custom webhook in Make, which would then automatically run an automation that marks that task as complete. (I demonstrate how to use custom webhooks in this Airtable podcast episode.)

Hope this helps!

If you have a budget and you’d like to hire the best Airtable consultant to help you with this or anything else that is Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld


2025 Update:

This is an outdated thread, so the information presented above is no longer accurate.

  • Since 2021, Airtable’s interfaces were specifically designed to solve this problem. No users need to be granted full access to the base anymore. 
  • Since July 2024, Airtable’s interfaces have been able to be shared publicly in a read-only state.
  • Since March 2025, Airtable’s portals feature has allowed interfaces to become a customer portal, so external users can view and edit their own records.
  • There are also 3rd-party customer portals that communicate with Airtable, such as NolocoJetAdminSoftrPory, and Glide. (I gave an entire one-hour webinar on Noloco called Building a Client Portal on Noloco powered by Airtable.)
  • External read-only users can edit your Airtable records for free by using Fillout’s advanced forms for Airtable, which allows users to update Airtable records with a form. (I demonstrate how to do this in this Airtable podcast episode.)
  • External read-only users can also edit your Airtable records for free by triggering a custom webhook in Make, which would then automatically run an automation that marks that task as complete. (I demonstrate how to use custom webhooks in this Airtable podcast episode.)

Hope this helps!

If you have a budget and you’d like to hire the best Airtable consultant to help you with this or anything else that is Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

 



Bill,


My statement was both truthful and correct. I just tested this again, for what?–the fourth or fifth time. I took a different base, shared it with another email account I have as editor. In different browser, opened that base in account #2, then changed account #2’s privileges to read only. That you can do that in itself is weird or at least interesting: a non-creator user can actually downgrade his or her own privileges! Anyway, now, from read-only account #2, I shared the base with a third email account, also as read-only (the only option, of course). Then in a third browser, I opened the base with the third account. Remember, #2 and #3 are now both read-only. And #3 is somebody totally unknown to #1, the creator.


My recollection is that kuovonne confirmed all of this. But wait, there’s more!


Then I went back to the “original” base (in my creator account) and made some edits. I added a table. I created some records, etc. I went back to the base in acct #3, and, yep, the new table was there, the new records were there.


So in what way is that a copy and not the original?


.



The only way in which what account 3 is accessing, is not the “entire base”, is that the read-only #2 and #3 accounts can’t edit anything.


But as I just showed, #2 and #3 are accessing the original base and can see edits and changes to it. And #2 and #3 can access and copy data in every view including locked and personal views. Copying is a simple matter of typing Cntl-A and Cntl-C. No need to write any code.


.


I feel like I’m being a major bore about this. But this is really important, no? And if wish, I’m happy to do a test with you or anybody else. Share a base with me. Give me read only privileges. Make changes to the base–new table, new records, edits. Create a locked and/or personal view. Let me know when you’re doing making changes. I’ll copy all the data in the base and send it back to you.


Will


Hi all! Wanted to follow up and close the loop on this thread. I’m excited to share that Airtable now supports workspace sharing restrictions so that Enterprise admins and workspace owners and Pro workspace owners can restrict the addition of new collaborators to specific workspaces or bases. Enterprise admins and workspace owners can also toggle a setting to prevent future share link creation on a given workspace. Thank you so much for the transparent feedback on this topic, we really appreciate it!


Hi all! Wanted to follow up and close the loop on this thread. I’m excited to share that Airtable now supports workspace sharing restrictions so that Enterprise admins and workspace owners and Pro workspace owners can restrict the addition of new collaborators to specific workspaces or bases. Enterprise admins and workspace owners can also toggle a setting to prevent future share link creation on a given workspace. Thank you so much for the transparent feedback on this topic, we really appreciate it!


Am I right in understanding that this just happened? Wow.



THIS IS HUGE.



What’s changed


So now, as of September 17, 2021:



  1. I create a new base in my Airtable Pro workspace. I’m a consulting developer.

  2. I go to Settings for that workplace and enable “Restrict adding new collaborators…”

  3. I go back to my workspace and either share the entire workspace or share an individual base with one or more of my clients as, say, editors.


Say I share the base with Clara Client, giving her editing privileges. She accepts the link, creates her login credentials, and she’s in. Now, if she wants to share the database with Cathy Colleague and give Cathy commenter privileges, she can use the Share button, but only to make a request. Threw me off for a sec that the Share button was still there in the Editor’s base, until I clicked it and saw the advisory note that explains that she can only make a request. The request is sent to me (base owner) for approval.


And if at some point, it’s necessary to remove someone’s access: I just delete them from the list of collaborators. I did this while I was connected to the base myself as my Alter Ego. The base was immediately closed on me. Excellent!


When the request comes to me as owner, I can



  • accept the request, giving the new user the privileges requested

  • accept the request but modify the new user’s privileges

  • deny the request

  • ignore the request (officially, by clicking “Ignore”)


If I approve the request, then Cathy Colleague is now invited to the base with Commenter privileges. This is awesome. Excellent. Very well done. Huge.



.



Cascading levels of access control?


Something else that’s absolutely awesome: After Clara Client’s request is accepted by me, Clara herself now has control over whether her own invitees retain their access. So say, Clara (with a little help from me) has got Cathy Colleague and Ellen Employee using the base, and then Ellen leaves the firm. Clara does not have to contact me to get Ellen’s access removed: She can do it herself.


I only tested this a couple hops away from myself as creator. I’m not entirely sure how it works if I share the base with Clara (boss of the billing department) and also with Kevin (office manager). If Kevin is also making sharing requests and I grant those requests, can Kevin see and remove Clara’s invitees or only his own? I’m assuming the latter but I didn’t test it out that far.


Have to say: This sort of thing is not impossible in FileMaker, but would be significantly more difficult to setup.


.



One more thing: Locking views


Actually, before I take the actions described above, I will almost certainly be going through the base’s views, and locking all the developer views that I do not want anybody to muck about with. I tested that too and it works great. I had shared base with my Alter Ego, giving Alter editor privileges. Alter was able to get into the base, and edit records including in locked views, but could not modify the locked views. Exactly as expected and as needed.


.



Counting teeth?


Okay, it’s not quite perfect, yet. For one thing it would be nice if we could create custom privilege sets, where (say) Billing Department users with Editor privileges only get to see views that pertain to Billing, while folks in the Fulfillment center only see views granted to their custom privilege set. But hey, I’m so grateful for what we just got that I’m going to promise not to mention this again for at least a week or two.


Seriously, this is huge. Major. THANK YOU AIRTABLE DEVELOPERS!


William


Reply