Adding a User to Interface Only

Yes, but unfortunately, Airtable has hidden away this option in a very secret spot that is extremely difficult to find.

First, the most important thing is to make sure that you start by removing those users from your base and workspace. They have to start off with ZERO ACCESS to your base to begin with.

Then, when you share the interface, you have to click on the "Invite by link" tab at the top. You can only do this through a link invitation, not through an email invitation.

Then, to the right of where it says "Copy Link", there is a little tiny gear icon that is almost invisible. Click on this invisible gear icon, which will take you to the next screen. 

On the next screen, you will need to uncheck the option that says "Allow access to data in the base".

It's a pretty unfortunate series of steps that we have to go through to make this happen. I hope that Airtable will make this easier in the future.

The ability to share only the interface without sharing the base is limited to workspaces that are on Team or higher plans.

If you are on the appropriate plan, you can simply click the 'Share' button on the interface, and by default sharing will be scoped just to interfaces that you select. If you'd like to share by link, make sure to only select a single interface to share, and then click on the 'Invite by link' tab. On paid plans, links created in this manner will only grant access to the interface by default.

Thanks for the information & clarification, @raghavsethi! However, before doing any of this, the users must be removed from any prior base/workspace access that they were given (in which those interfaces live). Is this correct?

Yes, if you're starting from the point where those users have access via the workspace or base, then you would have to revoke that access first.

Great! Thanks for clarifying! 😃

Hi @raghavsethi,

One of the big limitations of Interface Designer is that even if we invite a "read-only user" to view our interfaces, that read-only user is able to click on the "Share -> Manage Access" option, and then they are presented with a full list of all the names & email addresses of everybody else who has access to that interface.

These names & email addresses are often meant to be private information, especially for read-only users.

Additionally, read-only users are able to invite additional read-only users to view the interface as well. It's not really a huge problem if they invite additional read-only users to view the interface, but the big problem here is that they are able to see all the names & email addresses of everybody else who has been invited to the interface.

Here's a recent thread where this problem cropped up recently, but this has cropped up quite a bit amongst my own clients and amongst other Airtable customers in the various Airtable forums.

Would you be able to improve this functionality in the future, so that read-only users are no longer able to see the names & email addresses of all the other users?

Thanks! 🙂 

Since this has come up many times across various platforms, this question is worth addressing directly.

I 100% empathize that this feels like a frustrating limitation, especially since it seems like it should be easy to resolve (just hide the manage access modal for read-only users!). Unfortunately, there are some security considerations that are very important for us to get right before we can hide that screen.

The fundamental issue is that the collaborator list is required for several product features to work (even for read-only users). For example, if you have a grid in an interface with a dropdown user filter, we need to be able to populate the dropdown list with user information. If we populate the list with all users, the server would essentially be sending the web browser the same information as is displayed in the manage-access dialog (and any sophisticated user could view the entire list just by opening the Network tab in their browser developer tools). We take security very seriously, and want to avoid putting builders in a position where their data can be seen in ways they don't expect (e.g. you have competing vendors with access to the same interface and you don't want them to know about each other). Showing the manage access dialog helps communicate more visibly to builders that the interface user list is available to all collaborators.

Ideally, we would only send to every user a filtered list of other users, but we'd need to figure out what the criteria for this is. Some criteria we've considered:

1. Always redacting emails/pictures (which doesn't fully solve the problem, and makes it hard to distinguish between users with the same name)
2. Limiting to users in the same domain (which doesn't work for public email providers, and would affect vendors that do need to work together)
3. Somehow figuring out in realtime which other users every user can see based on data permissions (e.g. collaborator fields etc), and only limiting to that set (so computationally expensive that it could slow down the base).

One option is that we could just degrade things like the dropdown selector for read-only users.. but we also have very real editor use cases where hiding the user list is equally important (e.g. competing vendors needing edit access)! In these scenarios, the criteria for filtering becomes even harder to reason about (what if you actually want vendors to be able to assign tasks to each other?).

All of this is to communicate that we are very aware this is a painful limitation and that there are real technical problems that we need to work through. I don't have any timelines to share at the moment, but please know that we are thinking through how to solve this holistically. I will also note that any solution we come up with will likely have meaningful UX/workflow tradeoffs.

Thanks so much, @raghavsethi, for this very thoughtful and very detailed response! 😊

It is so wonderful to be able to get excellent & top-notch insights like this from an actual Airtable engineer about our questions & feature requests! 😀

Thank you so much for taking the time to post here!!

p.s. @raghavsethi I also wanted to add that I really appreciate Airtable's decision that you referenced above.

I totally agree with you that it is MUCH BETTER for us to visibly see the full list of users onscreen at all times — which lets us know that everyone has access to the list of users.

If Airtable had hidden away this list from us, yet sophisticated users could still access this list by opening the network tab in their browser tools, that would be a very unwelcome surprise.

Thanks again! 😁

I just want to second this. Thanks @raghavsethi for taking the time to response. I hope you and your colleagues find and get the time to do this more often! 

I appreciate the lengthy reply, but you've already solved this for the exact example that you have listed here. If your business or enterprise builders with large scopes aren't able to properly set up access controls then that is on them, and this is limiting the use of the product. 

Not only can users not even click on the list, because they are read only, even if they have full access the list can be reduced down to populate to only users in the person's organization(s), team(s), project(s), or even the user themselves by using your "Current user" selector and some carefully crafted security tables that we can already build. It's effectively doing this piece, and it's already in your tool.

"Somehow figuring out in realtime which other users every user can see based on data permissions (e.g. collaborator fields etc), and only limiting to that set (so computationally expensive that it could slow down the base)."

If you'd like me to show you the few different solutions we use to solve every related issue *except* the share modal I'd be happy to do so, but because of this we've stopped two enterprise builds and have had to find workarounds with third party front ends, or swap to SmartSuite when we prefer Airtable. 

Edit: Additionally I've attempted to pull this list from the network dev tools, and because the list won't populate in the browser, it doesn't seem to allow me to pull any unintended data. 

The specific example for read-only users I was talking about was this (and there are others):

In any case, I do want to acknowledge how painful this is and let you know that we're thinking through solutions.

In this case just add the same logic you already have in the filters in the other areas of the interface designer or have your builders use masking logic to hide the available options. If you're really worried about exposure to data, have your enterprise clients need to request this *specifically*. The same people who have large enough teams to do proper deployment testing, and utilize the drafting features in your tool are the same people who need to expand their userbase. 

Are there niches where this is potentially problematic? Yes
Are you definitely preventing your largest clients who you are specifically targeting from actually wanting to use your tool? Also yes

Hi @raghavsethi,

I've stumbled onto some confusion (possibly a bug?) when trying to invite read-only users to my interface. (These are people who do NOT have access to my base nor workspace. They have Airtable accounts, but I just want them to have access to my interface.)

On the "Share -> Invite by email" screen, I can type in all of their emails and set them to read-only users, but if I DON'T check the box that says "Notify people", they will not receive their email invitations. (Please see screenshot below.)

But isn't that the entire point of clicking the big blue "Invite" button? To invite them & send them a notification?

Why would I additionally need to add in the extra step of checking the box to "notify" them if I'm already clicking on the blue button that says "Invite"?

The reason that I previously unchecked the "notify" checkbox was because I thought that "Notify People" meant that everybody who already has access to my interface would get notified that a new person was added.

I feel like there could be some more clarification regarding the functionality of "Notify" vs. "Invite".

Thanks! 😀
Scott

Following advice on this thread, I created an interface, and shared it to a team member, who I verified now only has access to the interface. However, in order for leads to be assigned to them and populate within this interface, I still need to add them to my Workspace. Can someone please advise the appropriate process, as I do not want collaborators to have full access to company data.

You don’t need to add them to your workspace. You just need to create a User field and assign them to records there.

Thank you so much! I just needed to adjust the settings to uncheck the box that said to notify someone about joining a base. 

You’re welcome! Glad I could help! 🙂

Hi raghavsethi,

I watched Ilan Frank's talk in the last event, and you all shared your commitment to make AT a platform for App building.

I regret that this inability to provide privacy and adequate permission framework means AT isn't at all, as long as this isn't been solved, an App Building Platform.

I just finished building a robust system using AT Interface,as I believed your VP product, and I applied custom made permission implementation (so each user sees only the relevant records), just to find out I can't even get rid of the "View Data" button on the upper left corner of the Interface app screen, so all users simply click into the data table and violate all privacy concerns.

Please advise!

If you share the interface only, then your users will not have access to the “view data” button.

@ScottWorld, @annawright That's only true as long as you dont have to create permissions in the interface based on their user fields......

Nope. That’s not true. You can invite someone to interface access only, without giving them access to the entire base. In your User field, you need to make sure that you turn off the option that says “Notify Users”. See screenshot below.

Again, this is true only if you don’t use filters that use “current user” to apply privacy and permissions. Meaning, if your interface shows records based on the signed in user, you must add these users to the base. So it overrides the screenshot you provided. And that’s the essence of the problem.

No, you're not understanding. You can add people to a user field WITHOUT giving them base permission. That checkbox is what gives them base permission. Uncheck that checkbox and they will not have base permission. (If you've already accidentally added them to the base, you should remove their privileges first.)

In reality, Airtable should do a better job of naming that checkbox, because it's not accurately named. The checkbox makes it seem like that checkbox "simply notifies people", but in reality, that checkbox ACTUALLY gives people base permission. That checkbox controls whether you're adding them to the base or not.

Alternatively, there are other ways to limit interface record access, instead of using a User field. You can just use a normal email field to limit interface record access too.

@Dan_Montoya Would you mind reporting the issue above to the Airtable engineers? That User field checkbox seems to cause significant confusion... this exact same issue came up in another Airtable forum as well. 🙂

You should be able to use current user filters with interface-only collaborators - we have lots of customers that do this. I think where you may be getting tripped up is that you need to already have a user be 'a collaborator' to show up in the collaborator field dropdown. For self-serve plans, the only way to get people to show up in the dropdown is to invite them to any model connected to the base (workspace, base, interface). In your case, you should first set up your interface with current-user filters, then invite all the collaborators to your interface, and then reference them in  the collaborator field.

Also, to clarify, even if notify is on, you should still see a modal that allows you to make a choice as to whether you want to invite that user or not. If you choose to invite in a base setting, the invitation will be to the base.