Best Way to Build Secure Personalized Employee Dashboards in Airtable?

You would use Airtable’s interfaces for this, but you would only need to build ONE INTERFACE, not one interface page for each employee.

As long as each record is connected to a certain employee — either via their user account (in a user field or a lookup field) or via their email address (in an email field or a lookup field) — then you can filter each interface page to show users only their own records.

However, you will need to make sure that all of your employees signup for Airtable accounts. These accounts will be 100% free to you, as long as you make all of them read-only users. If you make them editors or commenters, then you will be charged for those accounts.

Airtable’s portals will give you a discounted price for editors and commenters. But you will not be able to use portals if your employees’ email addresses share the same domain name as your company. Portals are only for external email addresses.

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

Hi, thanks for sharing your opinion.

I agree that creating a read-only account for each employee would probably be the most secure and reliable option. However, I do have concerns about managing such a large number of accounts at scale.

Additionally, our employees are already using several different systems and tools on a daily basis, so I’m trying to avoid overwhelming them with yet another set of login credentials and another platform they need to access regularly.

That’s why I’m exploring alternatives that are both secure and easier to manage from an employee experience perspective.

To echo Scott, I think the simplest methodology here is to have everyone sign up for free Airtable accounts (plus you’ll get 5K in sign-up credits haha!) since it seems like they don’t edit or engage with the data, just view it. That’s if you can mandate this level of utilization.

Airtable really presumes that with 500 users you’ll be on some variant of an enterprise plan tho, so user management will be a nightmare. If you’re looking at a secure and scalable implementation to carry into the future, I do think you should look at an entry level Enterprise plan. To my understanding you mostly pay for Builders/Editors, and can have many more read only accounts. 

The other idea that would come to mind is using Softr, Glide, or another portal building tool to act as the UI layer for Airtable’s data backend.

Ah, posted at the same time you responded haha.

From this statement, it seems like what you really need is a front-end to display Airtable data that can be accessed via SSO integrated with another account (Azure or Google presumably?). I don’t have personal experience in developing those, but a quick perusal shows both Glide and Softr offer SSO options but only in their custom/enterprise plans (god knows the cost 🤷‍♂️)

+1 for Interfaces, would be simplest / cheapest

re: SSO

Airtable Business has SSO and so that could potentially be a cheaper option depending on how many users you’ve got?

re: I agree that creating a read-only account for each employee would probably be the most secure and reliable option. However, I do have concerns about managing such a large number of accounts at scale.

Hm, could you elaborate on the managing accounts bit and what we’d be trying to solve for here?

If it’s a concern about preventing employees who have left the company from viewing their past data, in the ‘Employee’ table you could have a checkbox field called ‘Active’ or something, and you could filter based off of that in the Interface?

Thanks all for the suggestions.

The concern is not about employees who have left the company, but rather about active employees accessing data they shouldn’t see.

For example, I may have Joe’s interface filtered to show only his own records, but if Joe is technically skilled enough, he could potentially remove or modify the filter and gain access to Michael’s data as well. That’s the specific risk Airtable is warning about.

We also have an internal system where we can embed the Airtable interfaces. However, I’m not sure whether users would still be able to modify/reset filters there and access additional data, or if the embedding would fully restrict that behavior.

​@Mladen 

No, you’re misunderstanding how Airtable’s interfaces work.

You would only give these people read-only access (or editor access) to the one new interface that you create for this particular purpose.

You would t give them access to other interfaces, you wouldn’t give them access to the base, and you wouldn’t give them access to the workspace.

These people would have ZERO ABILITY to see anyone else’s data, unless you upgraded one of them to become a creator on the base.

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

Hi ​@ScottWorld ,

I understand how Airtable interfaces and permissions work. The challenge in my case is that I don’t want to create and manage 500+ read-only employee accounts manually, especially since I’m on the Team plan and don’t have access to the Admin panel.

My idea was to create a dedicated interface/interface page for each employee and then share those pages on web so employees could access their own information without needing Airtable accounts.

The concern comes from Airtable’s own disclaimer regarding publicly shared interfaces. Airtable states that, in some cases, hidden data used to power interface elements may still be accessible to technical users through browser inspection/network logs.

For example, Airtable gives the case where a chart displays aggregated deal values, but the individual underlying values are still sent to the client and can potentially be inspected.

Because of that warning, I’m trying to understand whether publicly shared interfaces are truly safe for employee-specific data, even when filters are applied per employee.