How to Use Airtable Interface Designer to Build Client-Facing Apps

If you’ve ever shared an Airtable base with a client and watched them freeze up at the sprawl of fields, views, and linked tables — you already know the problem. The base that makes perfect sense to you looks like a spreadsheet that swallowed another spreadsheet to everyone else. Airtable Interface Designer exists precisely to fix that gap: it lets you build a clean, purposeful app layer on top of your existing data without touching the underlying structure.

This isn’t about making things look pretty. It’s about giving clients one focused surface to interact with — submit a request, check a project status, review a deliverable — without needing to understand how your base is actually organized. Here’s how to set it up properly.

What Interface Designer Actually Does (and Doesn’t Do)

Before you start building, it helps to understand what you’re working with. Interface Designer sits on top of your base — it reads and writes the same records, but presents them through a custom layout you control. Clients who are shared on the interface can see only what you’ve exposed, and they can only take actions you’ve explicitly enabled.

What it does well: filtering data so clients only see their own records, presenting information in a readable layout, accepting form input that writes directly to your base, and displaying summary stats or galleries without requiring any spreadsheet literacy. What it doesn’t do: replace a proper client portal platform for complex use cases, or give you pixel-perfect design control. It’s closer to a structured dashboard than a fully custom app — and for most solopreneur and small team workflows, that’s plenty.

Setting Up Your First Interface

Open your base and click Interfaces in the top navigation. From there, hit “New interface” and choose a starting layout. For client-facing use, the record review layout or the blank canvas are usually the best starting points — the blank canvas gives you the most control.

Your first decision is what data to surface. You’ll connect your interface to specific tables in your base, and from there you choose which fields appear. This is where the real work happens: think about what the client actually needs to see versus what you need internally. Status fields, deliverable names, due dates, and file attachments are almost always relevant. Internal notes, assignee fields, formula columns, and linked record IDs almost never are.

Add elements from the left panel — record pickers, galleries, grids, and forms are the most useful for client workflows. Each element connects to a table and inherits your field visibility settings. You can layer multiple elements on a single page to build a small but functional workflow: a summary section at the top, a grid of active projects below, and a form at the bottom for submitting new requests.

Filtering So Clients Only See Their Own Records

This is the piece most people miss when they first set up a client interface, and it’s critical. Without filtering, every client who accesses the interface sees every record in your base — including other clients’ projects.

Airtable Interface Designer supports conditional filtering on each element. You can filter records where a “Client” field matches a specific value, or more elegantly, you can use the current user’s email as a filter condition. If your base has a field that stores the client’s email address, you can filter to show only records where that field equals the logged-in user’s email. This turns one interface into a personalized view for every client — no duplication required.

To set this up: click on your grid or gallery element, open the filter settings, and add a condition using “Current user’s email” as the value. Make sure your base table has a collaborator field or email field populated for each record. Once it’s working, each client logs in and sees only their own data automatically.

Controlling What Clients Can Edit

Interfaces let you set permissions at the element level. A grid element can be set to read-only, or you can allow editing of specific fields only. This matters a lot for client-facing setups — you want them to be able to mark something as reviewed or upload a file, but you don’t want them accidentally changing a project status or deleting a record.

• Set grids to read-only by default; enable editing only on fields where client input is needed
• Use form elements for any structured input (new requests, feedback, approvals) rather than letting clients edit records inline
• Disable the ability to add or delete records unless your workflow specifically requires it
• Use the “Record detail” view to surface full record info without opening the full grid

The cleaner you make the permission model, the less you’ll have to explain to clients and the fewer mistakes will happen. Default to read-only, then add edit capability intentionally.

Making the Interface Feel Like a Real App

Small details make a big difference in whether clients actually use the interface or just email you instead. A few things that consistently improve the experience:

Name the interface something meaningful — not “Project Base Interface” but “[Client Name] Project Portal” or “Your Deliverables Dashboard.” Add a brief text element at the top that explains what they’re looking at and what they can do. Keep the layout single-column and simple; the temptation to add every piece of information usually results in an interface that’s just as overwhelming as the base itself.

Use gallery views for deliverables with file attachments — clients can scan thumbnails much faster than reading rows in a grid. If you have a status field, make sure the interface exposes it clearly at the top level of each record so clients don’t have to open individual records to find out where things stand.

Test the interface by sharing it with yourself via a different email (or using a guest share link) before you send it to a client. You’ll catch confusing elements and missing filters much faster seeing it through fresh eyes.

Sharing and Access Control

Interfaces can be shared in a few ways: you can invite specific people by email, share via a link that requires sign-in, or create a public link that anyone can access without an account. For most client setups, email invites or sign-in-required links are the right call — public links bypass the “current user email” filtering, which means everyone sees the same (unfiltered) data.

When you invite clients by email, Airtable creates a restricted collaborator role that gives them access to the interface only — not the underlying base. They won’t be able to navigate to your other tables, views, or automations. That’s exactly what you want.

One practical note: if you’re managing a lot of clients on a Pro or Business plan, keep a simple record in your base of which interfaces exist for which clients, when they last logged in, and whether the interface is still active. Interfaces have a way of multiplying and becoming orphaned over time.

When to Use It and When to Look Elsewhere

Airtable Interface Designer is a strong fit when your client interaction is relatively structured — status updates, document delivery, request submission, feedback collection. It works best when clients need to see data, not produce it in complex ways.

It’s less ideal if you need clients to have detailed discussions, manage their own sub-tasks, or access data across multiple bases at once. For those cases, you’re better off looking at dedicated client portal tools or integrating Airtable with something like Softr or Stacker that builds a more robust web app layer on top of your data.

But for the common scenario — a solopreneur or small agency wanting to give clients clean visibility into project status without the cognitive overhead of a full base — Interface Designer is often all you need. Build it once, share it, and stop answering “where are we on this?” emails.

If you want to go deeper, the autoflowguide.com workflow library has templates and walkthroughs for client-facing Airtable setups across different service types — a good starting point if you’d rather adapt something proven than build from scratch.