Yes, portals will do most of what you are looking for. It’s the exact same functionality as interfaces (portals are essentially just a different login process for interfaces), so you can test it out with interfaces before committing to portals.

You can’t filter interface pages by user groups, but you can filter them by the currently logged-in user’s email address, as long as their email is attached to the records that you want them to see.

This can be done with either an email field, or more likely, a lookup field that looks up their email address whenever you link them to a record. (So you could potentially design it so that one linked record field brings in a whole bunch of email addresses in the lookup field… thus simulating a “user group”.)

You can also use a collaborator field, but it’s much easier to use email addresses. 

You can not redirect to another base… all of your data would need to be in one base.

If you’re looking for more advanced portals for Airtable (that are also cheaper than Airtable’s interfaces), you’ll want to take a look at: Noloco, JetAdmin, Softr, Pory, and Glide.

Also, Fillout is a very basic portal, if you only need people editing one record at a time (such as updating their own customer profile information).

Hope this helps! If you’d like to hire the best Airtable consultant to help you set this up, or to help you with ANYTHING Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

Hi ​@luismi,

1. You can manage users using a group logic by creating a “Team Members” table and assigning your users to groups/departments/etc and using automations to apply the specific logic that you desire.
2. Portals achieves what you look for. Additionally you can consider integrating external services such as Softr that allow you to provide a client portal with a custom url: it can look as your own professional web page / app.
3. Yes, but you can probably maintain the entire logic within the same base to minimize complexitey.

Beyond linking collaborators to the current user, is it possible to associate users with a group and dynamically use that group to filter views in interfaces?

Yeap, try using a ‘Users’ and then a ‘User Groups’ table like so:

This’ll let you filter it the way you want:

Does the Portals feature provide the functionality we need? Since there is no trial, we cannot validate it ourselves—perhaps someone else has insight into this? (Note: Yes, we are aware of alternative solutions for Portals, but we haven’t explored them yet.)

Portals is pretty much just Interfaces, so if you can get it running in Interfaces then Portals will work for you

---

If we use multiple bases, can we route a Portal user to a specific base with its corresponding interface?

Hm yeah, it’s possible but they’d get billed as a regular seat instead of Portal I think, which rather defeats the point

Specifically, this bit from the FAQ:

You’d also have to build your own buttons and logic to get the users where you want them to go too

1. You can’t directly assign users to a group. Instead, create a Team table where each member is assigned to a group. Then, in your main table, link each record to the relevant team members. You can use a lookup field to reference their group and filter accordingly.
2. Yes, a portal will help you achieve what you're looking for.
3. Yes you could do it, but the logic to do that can be complex. 

Taha, Airtable Advisor

Thanks all for the detailed information provided, after a long internal review here, we are going to do a kind of a mix.

We will setup the environment, whenever it is possible and pending to be tested, to link a record to a group, as per our initial approach each record must have a group attached. Considering we have a table of users linked to a group on a specific table.

That should allow us to link each record to a tenant, however it is not clear if this approach will work with the interfaces, we read a lot about current user and current user’s email, however the record can be manipulated by several users. That shouldn’t be an issue. as per understanding Airtable automatically locks a record when a user begins editing it to prevent simultaneous edits.

Further tests are pending.

Thanks all

​@TheTimeSavingCo this is very confusing

It might be us, but it seems that both statements are opposite each other.

Our understanding is… In one is saying that if you have team plan and it has access > read-only, which is going to be required on our idea, then it is billable under your team plan workspace, which we believe it is 20USDx12months??

But right below it is saying that you buy the portal seats then it is possible to allow 15 portal users with editor or commenter access.

Anyone has a clear view on this?

Hey ​@luismi,

Re: That shouldn’t be an issue. as per understanding Airtable automatically locks a record when a user begins editing it to prevent simultaneous edits. 

I don´t think that is actually the case! Records can be updated by multiple users simultaneously. How exaclty will users be editing-updating records? Just to fully understand the use case and see whether we can find a workaround.

Mike, Consultant @ Automatic Nation

Yeah there’s a lot going on in that section and you may want to open a ticket with support to get this cleared up

Here’s my understanding:

1. Read only Portal users aren’t billable
2. Editor Portal users are billable at the 15 seats for $120 rate, so 8 dollars (Teams)
3. If a Portal user is added to Interfaces in multiple bases as an Editor, they’ll be billed at the normal collaborator rate of 24 dollars
   1. i.e. If you add a Portal user to multiple Interfaces in the same base, that’s fine, but if you add them to two Interfaces that are in separate bases, then you’ll get billed more

​@Mike_AutomaticN 

The idea is the end-users will interact just over the portal with a limited and well defined interface, multiple users might be working on the same record at the same time. However, as per my tests here, the probability of a collision is low, and even if that appears, initially, the audit trail with who and what changed were done should be acceptable to debug any issue further

​@TheTimeSavingCo 

I think you're right—the support ticket response was relatively vague, with a lot of copy-pasting, some questions were unanswered/deflected. We will go deeper with them once we approach some stages, we can’t spend further time on not so useful ping-pong chat.

In summary, I believe it is linked to $120 USD for 15 users. The $8 per user rate is specifically tied to the business plan.

​@TheTimeSavingCo 

I was able to reproduce the issue with users and users group and records table. and, in fact, the filter allows me to set a dynamic filter based on users current email. So that is working 100%

Now, I am trying to expand the idea to my setup, however the filter “current’s user email” does not appear, even if I have an email field.

So basically the setup is documents tabke , linked to group (called entity ID)  and users emalls from entity contacts table as a lookup field, entity table contains users emails

Now, I go to interface and set a page were I would like to filter docs by user, so I choose documents table and I try to set a filter based on the current ‘s user email ,but it does not display it.

So, I suspect fhe filter just appear whenever the tables are with specific names as users users, and groups? filers are correctly linked and the type of the field is correct.

I sorted it out

​@TheTimeSavingCo 

The proposed solution only works when all tables are within the same base.

This is a limitation, as we plan to have two bases—one for internal business operations and another for external/client interactions. Security reasons and operative.

However, we sync at least three tables from our internal business base to the external/client base for certain operational purposes. With that in mind, we built a new groups/users table in the external base, incorporating previously imported data along with some user account parameters. While it appears to function perfectly in grid view, the filter “current user’s email” is not available in the interfaces.

It seems that synced tables, despite containing the data, behave differently

This will force us to re-think the model one more time.

Does anyone know a workaround and/or if Airtable is planning to alter this behavior?