How to stop duplicating the same Airtable interface for every client

Client number nine needed a portal by Friday. The fastest way to get there was to duplicate client number eight's interface, swap the logo, adjust the filter, and move on. Nobody sat down and decided this would be the process. It just became the process, one client at a time.

By client fifteen, updating a single field means remembering which of fifteen near-identical interfaces still needs the fix. By client thirty, nobody fully remembers which ones are current. This is one of the quieter ways Airtable setups become harder to maintain as the business grows, and it usually has nothing to do with running out of room.

TL;DR

• Airtable caps interfaces at 50 per base and pages at 50 per interface (Airtable Support, 2026). Duplicated interfaces can only be copied within the same base, never moved to another one.
• Most firms notice the maintenance overhead well before they notice the limit itself.
• Airtable's own documentation recommends a single interface with a filter tied to the viewer's email instead of one interface per client.
• That native filter controls which records a client sees, not which fields. Sensitive fields like internal margin notes can still need a separate configuration to stay hidden, which is often why teams default to duplicating instead.
• Many firms eventually move to a setup where permissions are managed per user instead of maintaining separate interfaces for each client.

What actually causes the duplication habit?

It usually starts small. One client needs a slightly different view of their project status, so someone duplicates the existing interface rather than reworking the filter logic on the original. It's faster, and it works. The second client needs the same thing. So does the third.

It's rarely a deliberate decision. It's simply the quickest way to get a client live when time is tight. The cost shows up later, when a pricing field needs updating everywhere, or a client's logo changes, or the whole layout needs a new column, and someone ends up making the same update over and over again.

How many interfaces can one Airtable base actually hold?

Airtable caps this deliberately. According to Airtable's own support documentation, "for functional reasons, we've capped the number of interfaces per base at 50. Additionally, there is a limit of 50 interface pages per interface" (Airtable Support, updated 2026). There's also a hard rule worth knowing before you build around duplication as a strategy: you can duplicate an interface within the same base, but Airtable does not support duplicating an interface or an interface page into a different base, since an interface's configuration depends on that specific base's fields and tables.

The table below lays out where the ceilings actually sit.

For the wider picture of where this cap sits alongside records and automations, see our full Airtable pricing breakdown.

What does Airtable itself recommend instead of duplicating?

Airtable's documentation points toward a single interface with a record filter set to the viewer's own records, using an email or user field to match each client to only their data. This is Airtable's recommended approach, and it's a good one for reducing maintenance.

It also means fewer places to make the same edit. One filtered interface replacing thirty duplicated ones is a real improvement, and worth doing regardless of what you decide next.

Why doesn't the built-in filter fully solve it?

The viewer's records filter controls which rows a client sees. It doesn't control which fields they see within those rows. If your project table includes an internal margin column, a private note field, or anything else that shouldn't reach a client, the native filter alone won't hide it consistently across every layout type.

Airtable's own documentation on public interface pages is direct about the limits here too: field values used for charts, and conditionally hidden fields, can still be visible to a technical user inspecting the page's network traffic, even when they don't appear on screen (Airtable Support). For some teams, this is where they decide they need a different way to manage permissions.

What breaks first as the number of clients grows?

It's rarely the 50-interface cap itself. Long before that number, three areas usually become harder to manage:

• Consistency. A layout tweak, a renamed status, or a new column needs to be repeated across every duplicated interface, and it's easy to miss one.
• Ownership. Nobody remembers which interface belongs to which client's current setup versus an old test copy that should have been deleted.
• Trust in the data. If two clients are seeing subtly different versions of the same underlying process, small formatting drift starts looking like inconsistent service.

None of this shows up as an error message. It shows up as time, the kind captured in Asana's Anatomy of Work Index (2026), which found that roughly 60% of the average workday goes to "work about work" like chasing down the right version of something rather than doing the actual client work. Maintaining thirty duplicated interfaces is a textbook example of that pattern.

How do you get to one interface that adapts per client?

The underlying goal, whether you stay on Airtable's native tools or add a layer on top, is the same: one interface that changes what it shows based on who's logged in, rather than thirty separate copies that all need to be kept in sync by hand. In practice, this happens in three steps.</p>
- Consolidate your existing duplicated interfaces down to one using Airtable's native "viewer's records" filter to show each client only their own records. This alone removes most of the maintenance tax, since one change now updates everywhere instead of in thirty places.

- Identify which fields are actually sensitive per client, like margin, internal notes, or anything else the native record filter can't hide, since that filter controls rows, not columns.

- Add a permission layer that handles both record and field-level rules on that same single page, so it adjusts automatically based on who's logged in, without a second copy to build or maintain.

For businesses managing lots of client-facing workflows, this is often where a dedicated operational layer starts to make sense. Instead of maintaining a separate interface for every client, you can keep a single interface that adapts automatically based on who's signed in.

‍With Noloco, Airtable remains your soure of truth. Noloco becomes the layer where your team and clients actually interact with that data, applying record and field-level permissions automatically.

Final thoughts

The 50-interface limit is real, but for most growing teams it isn't the first challenge they notice. Keeping dozens of nearly identical interfaces in sync usually becomes the bigger maintenance task long before the limit itself. Airtable's own filter-based fix helps, but it stops at the record level, not the field level, which is one of the reasons some teams eventually look beyond native filters.

If this is already familiar, and you're also noticing per-editor costs creeping up or automations quietly failing, it's worth checking whether duplication is one of several signs your operations have outgrown what they're comfortably managing today.

Frequently asked questions

How many interfaces can I actually create in one Airtable base?
Up to 50 interfaces per base, and up to 50 pages within any single interface (Airtable Support).

Can I duplicate an Airtable interface into a different base?
No. Airtable's documentation is explicit that interfaces can only be duplicated within the same base, since the interface configuration depends on that base's specific fields and tables.

Does Airtable have a built-in way to avoid duplicating an interface per client?
Yes. A single interface can filter records by the viewer's own email or user field, showing each client only their own records without needing a separate copy.

Does that built-in filter also hide sensitive fields from clients?
Not fully. It controls which records appear, not which fields within those records are visible, so sensitive fields often need additional handling to stay private across every layout type.

Is duplicating interfaces actually against Airtable's terms or a bad practice?
No, it's a supported feature and a reasonable short-term fix. The issue is maintenance cost at scale, not policy: every duplicated interface needs to be updated by hand when something changes.

What's the difference between fixing this inside Airtable versus adding a frontend layer?
Fixing it inside Airtable means consolidating into fewer interfaces with record-level filters, which helps but doesn't cover field-level privacy. A dedicated frontend layer on top of Airtable can apply both record and field-level rules to a single page automatically, without duplicating anything. See how Redrock Entertainment cut costs by 60% with Noloco.

Related resources

• Airtable Pricing 2026: Plans, Hidden Costs & the Best Frontend for Portals: where the interface cap sits alongside record and automation limits.
• How Redrock Entertainment cut costs by 60% with Noloco and Airtable
• Airtable Client Portal: Secure Permissions & Security Guide (2026): a deeper look at the record and field-level permission gap.
• The Airtable automation limit nobody warns you about: the sibling ceiling many of the same firms hit around the same time.
• Noloco Permissions: how record and field-level rules apply automatically per user.
• Noloco for Airtable: how the two-way sync with your existing base works.

Wondering if interface duplication is just the first crack, or part of a bigger pattern? Continue to 6 signs your firm has outgrown Airtable as its source of truth to check the other five.