Airtable Enterprise Governance: Admin Panel, SSO/SCIM, and Taming Shadow Bases

Every Airtable rollout that works has the same second act. Teams love it, bases multiply, and one day someone in IT asks a question nobody can answer: how many bases do we have, who is in them, and what customer data is sitting in the ones we do not know about? That is a governance problem, not a build problem, and Airtable's Enterprise tooling is where you solve it.

This tutorial walks through the admin surfaces available on Airtable's Business and Enterprise Scale plans, in the order you should actually use them, and gives you an audit you can run in an afternoon.

Who this is for

You need admin rights on an Airtable enterprise account (the admin panel is not available on Team plans). If you are on Team and reading this because sprawl is already hurting, the shadow-base inventory in step 4 still works — you just do it by asking humans instead of querying the account.

Step 1: know what the admin panel actually shows you

The admin panel is the account-wide view: users, workspaces, bases, groups, and reports. Before you change any setting, spend twenty minutes reading it and write down four numbers:

• Total licensed users, split by seat type. Compare against your invoice.
• Users on your verified domain vs external collaborators. External collaborators are the ones who leave the company and keep access.
• Workspace count and how many have no owner still employed.
• Bases marked as shared externally.

Those four numbers are your governance baseline. Re-record them quarterly. Change over time tells you more than any single snapshot.

Step 2: claim your domain, then turn on SSO

Domain verification is the prerequisite for almost everything else. Once Airtable can prove you control yourcompany.com, the account can manage every user with that email domain — which is what makes SSO enforcement and provisioning meaningful rather than advisory.

Order of operations that avoids lockouts:

1. Verify the domain (DNS TXT record — your IT team owns this, not you).
2. Configure the identity provider connection (SAML with Okta, Entra ID, Google Workspace, or OIDC) and test it with two or three pilot users while password login is still allowed.
3. Only then enforce SSO for the domain, so password and Google-button logins stop working.
4. Keep at least one break-glass admin account documented with your IT team.

The step people skip is 3. Configuring SSO without enforcing it means half your users still sign in with a password they set in 2022, and your offboarding process quietly does nothing.

Step 3: provision and deprovision with SCIM

SSO controls how people log in. SCIM controls whether the account exists at all. With SCIM configured, your identity provider creates Airtable users when someone joins, updates them when they change teams, and deactivates them the moment HR terminates them in the source system.

Two practical notes:

• Map groups, not individuals. Push identity-provider groups into Airtable and grant workspace access to the group. Then "give the new analyst access to the ops workspaces" is an IdP membership change, not eleven clicks in Airtable, and it is auditable.
• Deactivation is not deletion. A deactivated user's records, comments, and automations remain. Decide deliberately what happens to bases they personally owned — which is exactly why personal ownership of production bases is a bad pattern (see step 5).

Step 4: inventory the shadow bases

This is the part that produces the uncomfortable meeting, and the part that produces the most value.

1. In the admin panel, export or list all bases with their workspace, owner, last-activity date, and external-sharing state.
2. Sort by last activity. Anything untouched for six months is a candidate for archive; anything untouched for eighteen months with an ex-employee as owner is a candidate for deletion after a snapshot.
3. Filter to bases with active shared views or shared forms. For each one, ask: does this link expose customer data, and does it need a password or an expiry? Publicly shared views are the single most common real-world Airtable data leak, and they are usually created by someone helpful in a hurry.
4. Filter to bases with external collaborators. Confirm each external person is still engaged with you.
5. Tag every remaining base with a data classification: Public, Internal, Confidential, Regulated. Bases in the last two categories get named owners and a review date.

Track the whole inventory in — of course — an Airtable base. One record per base, fields for owner, classification, last review, and remediation status. It is the only governance artefact anyone will actually keep updated.

Step 5: fix ownership before it fixes itself

The most common structural fault we find in enterprise accounts is a business-critical base living in a personal workspace owned by one individual. When that person leaves, access transfer is an IT ticket at the worst possible moment.

The pattern that holds up:

• Production bases live in team workspaces, never personal ones.
• Every production base has two named owner-level humans, plus a group with owner access.
• Automations and integrations authenticate as a service account, not as whoever happened to build them. Personal access tokens tied to a departing employee are a scheduled outage.
• Document the owner, the purpose, and the upstream/downstream integrations in the base description field. It takes ninety seconds and saves an archaeology project.

Step 6: set the guardrails that prevent recurrence

Governance that relies on people remembering does not last. Use the account-level settings to make the safe path the default:

• Restrict who can create workspaces, so new sprawl arrives through a request rather than a whim.
• Limit external sharing — many accounts can require passwords or block public shared links entirely. If a team needs external access, route them to a proper client portal with a secure interface instead of a public URL.
• Control which integrations and extensions can be installed, and review the list of third-party OAuth grants against the base.
• Turn on audit log export and send the events somewhere your security team already looks. An audit log nobody reads is theatre; an audit log feeding your SIEM catches an unusual export.
• Decide your AI posture explicitly. Whether AI features are enabled, in which workspaces, and against which classified data is a governance decision. Write it down before someone points a field agent at a regulated table.

Step 7: make it a routine

Governance is a calendar item, not a project. A workable cadence:

• Monthly: licence reconciliation and new external collaborators.
• Quarterly: shadow-base inventory refresh, shared-link review, classification updates for new bases, and your four baseline numbers.
• Annually: SSO and SCIM configuration test, break-glass account test, and a full permission review of every Confidential or Regulated base.

Pair this with a backup regime — the admin panel does not replace one; see our Airtable backup and disaster recovery guide — and a documented change process for schema edits.

The trade you are making

Every control above adds friction. Airtable's value is that an operations lead can build the thing they need on Tuesday without a ticket, and if you lock the account down to the point where that is impossible, you have paid enterprise prices for a worse database. The goal is not to stop people building. It is to know what exists, keep regulated data in a small number of well-owned bases, and make sure nothing important dies with a departing employee's login.

BaseBrainers runs governance audits and rollouts as part of our enterprise-level Airtable solutions and security and compliance work. If your account has grown faster than your controls, get in touch and we will start with the inventory.