Airtable Interface Designer: The Complete Guide to Building Custom Apps

The grid view that opens when you create an Airtable base is great for power users and terrible for everyone else. Show it to a salesperson, a marketing manager, or your CEO and you'll get a polite "this is a lot." Interface Designer is the fix. You build a curated screen — only the fields they need, only the records they're allowed to see, with the buttons they actually use — and they never have to look at the raw base again.

This guide walks you through every layout type, the permissions model, and the patterns we use on real client projects. By the end you'll be able to design dashboards, record review screens, intake forms, and approval flows without writing code.

What Interface Designer Is (and Isn't)

Interfaces are custom screens layered on top of your base data. They share the same underlying records, so a change made in an interface saves to the base immediately. You're not creating a separate copy of the data — you're creating a different window into it.

Interfaces are not a substitute for a public-facing app. They're for internal team users — your staff, contractors, and collaborators who have Airtable access. If you need to share data with thousands of external users without giving them Airtable seats, you'll still reach for Softr or a similar portal tool. Interface Designer fills a specific gap: the people inside your business who need to do focused work without learning how Airtable bases are structured.

The Nine Layout Types

Every page in an interface uses one of these layouts as its starting point. You can mix multiple layout pages in the same interface — for example, an Overview page that links to a Dashboard, a Record review, and a Form.

Pick the layout based on the action your user needs to take, not the data you have. If they need to spot trends, that's a Dashboard. If they need to go through items one at a time, that's Record review. If they need to fill something in, that's a Form. Match the layout to the work.

For the full layout reference, see Airtable's Interface Layouts documentation.

Building Your First Interface

The fastest way to learn Interface Designer is to build a real one. Here's the flow.

1. Open a base, click Interfaces at the top, then Start building.
2. Pick a starting template or choose Start from scratch.
3. Give the interface a name and pick which tables it can pull from.
4. On the canvas, click Add page and choose a layout type.
5. For each layout, point it at a source table and add elements.
6. Configure filters and sorts so each user sees the right records.
7. Click Publish when you're ready to share with your team.

Two things to know before you start dragging elements around:

• Layouts are tied to a source table. A Dashboard can pull from many, but most layouts focus on one. Pick the table that matches the unit of work the page represents — clients, projects, invoices.
• Filters on a page are independent of filters in the base. The grid view of your Clients table might filter out archived clients, but your interface page won't unless you re-create that filter inside the interface.

Pattern: A Leadership Dashboard

The most common first interface is a leadership dashboard. It answers the question "how is the business doing this month?" without making anyone open the base.

What goes on it:

• Three to five number elements at the top — revenue this month, deals closed, open invoices, projects in progress
• One or two bar charts for trends — revenue by month, deals by stage
• A filtered list at the bottom for at-risk items — projects past due, invoices overdue more than 30 days
• A time-period filter at the top so the viewer can switch between this month, this quarter, year-to-date

Two design rules we follow every time:

1. Never show more than seven elements on one dashboard page. People can't process more than that at a glance. If you have more to show, break it into multiple pages with an Overview as the landing screen.
2. Round numbers and use the right unit. A "Total Revenue" number that reads $184,237.45 is harder to scan than $184K. Use the number formatting options to round to the precision that matters.

Pattern: A Record Review Screen for Approvals

Record review is the layout designed for "go through these one at a time." It shows a list on the left and a detail panel on the right, with keyboard shortcuts to move through records quickly.

The classic use case is approvals — a designer drops finished work into Airtable, the client opens an interface and sees a queue of items to approve, and they click Approve or Reject for each. Behind the scenes, an automation moves approved items to the next stage and notifies the team.

Configuration steps:

1. Add a Record review page sourced from your Items table.
2. Set the filter to Status = "Awaiting Approval" so only relevant records appear in the queue.
3. In the detail panel, hide all fields except the ones the reviewer needs — the asset preview, a description, and the approval buttons.
4. Add two buttons to the detail panel: Approve (sets Status to "Approved" via a button action) and Reject (opens a comment field and sets Status to "Rejected").
5. Optionally trigger an automation on the status change to notify the next person in the chain.

The result is a screen that does one job extremely well. The reviewer never has to navigate, search, or scroll — they open the interface, work through the queue, and they're done.

Pattern: An Intake Form

Forms in Interface Designer are different from standalone Airtable forms. They live inside the interface, so they're behind your team's login and you can pre-fill fields based on the logged-in user.

Use a Form layout when you want a team member — not a public visitor — to submit data through a clean interface. New project briefs, support requests, expense submissions all fit. For public-facing forms, the standalone Form view of a table is usually simpler.

Tips:

• Use conditional fields to hide questions that don't apply. If the user selects "Existing client" as the project type, hide the new-client onboarding questions.
• Set field defaults that make sense for your context — current date, current user, the user's department.
• Add a success page after submission that confirms what happens next and links back to the relevant interface.

Permissions and Interface-Only Users

The permissions model has three layers stacked on top of each other.

Workspace and base permissions. Standard Airtable access — Owner, Creator, Editor, Commenter, Read-only. Users at this level can open the base directly.

Interface permissions. Per-interface settings layered on top. A user with Editor on the base might be set to Read-only on a specific interface, so they can view the dashboard but not change records through it.

Interface-only access (Team plan and above). A special seat type for users who should only ever see interfaces, never the base. They can't open the underlying tables. They see the interfaces shared with them and nothing else. This is the right seat for non-technical team members who don't need to know the data structure.

The "current user" filter is the trick that makes this all work at scale. If you have an Assignee field on a Tasks table that's set to a Collaborator type, you can filter the interface so each user only sees tasks assigned to them. One interface, hundreds of users, every person sees only their own work.

Buttons That Run Automations

A button in an interface can do one of four things:

• Open a URL
• Create a new record
• Update the current record (set one or more field values)
• Run an automation

The fourth option is where buttons become powerful. You wire the button to an automation with a "When button is clicked" trigger, the automation receives the current record's ID, and it can do anything an Airtable automation can do — call an external API, generate a document, send an email, update related records across multiple tables.

A practical example: a sales rep is looking at a Deal record in an interface. They click Send Proposal. The automation triggered by that button takes the deal's information, generates a proposal document in Google Docs, attaches it to the record, emails it to the client, and changes the deal status to "Proposal Sent." The rep never sees any of this — they just see the status update on screen.

For more on automations, see our Airtable Automation Guide.

Conditional Fields and Why You'll Use Them

Conditional fields show or hide based on the value of another field. They keep your screens clean and make complex forms feel simple.

Use them when:

• A form has questions that only apply in some cases — only ask "What's the shipping address?" if "Delivery method" is set to Shipping.
• A record detail view has fields that only matter at certain stages — only show "Contract Signed Date" when Status is "Active."
• You want to guide users through a workflow without overwhelming them upfront.

Configure them by selecting the field in the layout editor and adding a condition under the field's settings. The condition can reference any other field in the same record.

Common Mistakes to Avoid

A few patterns we see often in client bases that get rebuilt:

• Too many pages in one interface. If your interface has 15 pages, your users will get lost. Split it into multiple interfaces by audience — one for leadership, one for sales, one for ops.
• Mixing roles on one page. A page that's half manager view and half rep view ends up serving neither well. Build separate pages for separate roles and use permissions to control access.
• Forgetting to filter. A new layout shows every record in the source table by default. Always add a filter before publishing, even if it's a permissive one.
• Skipping the Overview page. When an interface has more than three pages, start with an Overview that explains what each page does. It saves you from getting the same orientation questions every week.
• Building interfaces before the base is stable. If your fields and table structure are still changing, interface elements will break. Get the base schema right first, then build the interface.

When to Use Interfaces vs Other Tools

Interfaces have a clear sweet spot: internal apps, fast to build, for users who already have Airtable access. Inside that lane, they're hard to beat.

Where to Go Next

If you're new to Airtable, start by stabilizing your base schema and learning linked records — interfaces work best on top of clean relational data. If you've built a few interfaces and want them to do more, the next step is wiring them to automations via button actions, which is where Airtable stops feeling like a database and starts feeling like a real internal application.

The official Interface Designer documentation covers every element in detail, and Airtable's layout overview is a useful reference when you're deciding which layout to use for a new page.