Help

Adding a User to Interface Only

13574 35
cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
annawright
4 - Data Explorer
4 - Data Explorer

I would like to assign leads within a base to a member of my team, but do not want them to be able to have full access to the base. I would prefer them to only see the base as an interface, and only be able to read and access leads that have been shared with them. Is this possible?

35 Replies 35
ScottWorld
18 - Pluto
18 - Pluto

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.

raghavsethi
Airtable Employee
Airtable Employee

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.

ScottWorld
18 - Pluto
18 - Pluto

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.

ScottWorld
18 - Pluto
18 - Pluto

Great! Thanks for clarifying! ๐Ÿ˜ƒ

ScottWorld
18 - Pluto
18 - Pluto

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.

ScottWorld
18 - Pluto
18 - Pluto

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!!

ScottWorld
18 - Pluto
18 - Pluto

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! ๐Ÿ˜