Interface Designer is how you turn an Airtable base into an app. The base holds the data; an interface is the set of screens each kind of user sees, with only their records, their fields, and their buttons. In 2026 it is the default way to put Airtable in front of anyone who is not a base builder, and with Omni able to generate a first draft from a description, there is no excuse for a team still working out of raw grid views. This guide covers the decisions that matter: pages, audiences and permissions, layouts, and publishing.
When an interface beats a shared view
A shared view link is fine for a read-only list that one person checks occasionally. An interface wins as soon as any of the following is true:
- Different people need different slices of the same data.
- Someone needs to edit a few fields but must not touch the rest.
- You want a dashboard, not a table.
- Users should never see the base itself (clients, contractors, the wider company).
- You want buttons that run automations.
If you are sending someone a view link and then explaining in the email which columns to ignore, build an interface.
Step 1: list the audiences and their jobs
Write a two-column list: who, and what they do in the base. For a recruiting base it might be:
| Audience | Jobs |
|---|---|
| Hiring managers | Review candidates for their role, leave feedback, move stage |
| Recruiters | Everything: add candidates, schedule, update any field |
| Interviewers | See today's interviews, submit a scorecard |
| Leadership | Pipeline dashboard, time-to-hire |
Each row becomes an interface, or at least a page group with its own permissions. Do not build one giant interface for everyone; the whole point is that each audience sees a small, relevant app.
Step 2: create the interface and its pages
From the base, open Interfaces and create a new one. You can start blank, pick a layout, or describe it to Omni. Whichever you pick, you will be editing it, so choose the closest starting point.
Add pages per job. The layouts that do most of the work:
Record review. A list of records on the left, the selected record's details on the right. Use it for anything that is "work through these one at a time": candidate review, invoice approval, ticket processing. Configure which fields show in the list (keep it to three or four) and which show in the detail pane, and set which of those are editable.
Dashboard. Number, chart, and list elements on one page. Good for leadership pages and anything checked at a glance. Resist the urge to put fifteen charts on it; three numbers and two charts that answer the question are better than a wall.
Form. Collects a new record. Interface forms support conditional fields, field descriptions, and prefilled values, and unlike the old form view they can be restricted to logged-in users.
Grid / gallery / kanban / calendar / timeline. The familiar view types as interface pages, with the advantage that you control the fields, the filter, and the editability per page.
For the hiring-manager interface: a record review page filtered to candidates for roles where the current user is the hiring manager, and a form page for feedback.
Step 3: filters that follow the user
The feature that makes role-based interfaces work is filtering by the current user. On a page, set the filter to a collaborator field (for example Hiring manager) equals the current user. Each hiring manager opens the same page and sees only their candidates. Combine with a status filter so closed roles fall away.
If the "who owns this" relationship goes through a link (candidates link to a Role, and Role has the hiring manager), add a lookup of the collaborator field onto the Candidates table so the page filter can use it directly.
Step 4: permissions and audiences
Interfaces have a permission model separate from the base:
- Who can open the interface. Share it with specific people, with everyone in the workspace, or with the base's collaborators. People you share an interface with do not automatically get base access; that is the feature that makes portals possible.
- What they can edit. Per page, each field element can be read-only or editable. Set editing deliberately. A hiring manager should be able to change
StageandFeedbackand nothing else. - What they can create and delete. Record creation and deletion are page-level settings; turn them off unless the job requires them.
- Interface-only access. Plans that support it let you give someone access to an interface without making them a base collaborator at all. This is the right model for clients, vendors, and anyone outside the core team.
A habit that saves trouble: before publishing, open the interface as a test user in the lowest role and try to do something you should not be able to do.
Step 5: buttons and automations
Buttons on interface pages can update a record, open a URL, navigate to another page, or run an automation. This is where an interface stops being a viewer and becomes an app. An "Advance to interview" button that sets Stage, stamps Stage changed at, and triggers the scheduling automation is far better than asking users to edit three fields correctly.
Keep button labels as verbs a user would say: "Approve", "Request changes", "Send quote".
Step 6: publishing and change management
Interfaces have an edit mode and a published state; changes are not visible to users until you publish. Use that. Make a batch of changes, walk through the pages as each audience, then publish once and tell people what changed.
Naming matters for adoption. Name the interface by audience and purpose ("Hiring Managers – Candidate Review") and name pages by the job ("Review candidates", "Submit feedback"). Users should not need a tour.
Omni-generated interfaces
If you ask Omni to build an interface, expect a reasonable layout that shows too many fields, uses raw field names as labels, and has no permission configuration. Treat it as a wireframe: delete elements down to what the audience needs, relabel, set the per-page filter on the current user, configure editability, and set sharing. The time saved is real, but it is in the layout step, not the governance steps.
Common mistakes
- One interface, every field. If a page shows more than about ten fields, someone will ask for a spreadsheet instead.
- Forgetting the reverse. Users editing a status through an interface need to see the result. Give every action visible feedback, such as a status badge on the same page.
- Filters that depend on data quality. A current-user filter on an empty collaborator field shows nothing. Make the field required at intake or default it with an automation.
- Sharing the base to fix an interface problem. If a user cannot see something, add it to their page; do not give them the base.
Summary
List the audiences and jobs, build one focused interface per audience, filter on the current user, set permissions per page, add buttons for the real actions, and publish deliberately. An interface built this way replaces the spreadsheet export and the weekly status email in one go.
BaseBrainers builds role-based Airtable interfaces for teams of five to five hundred; see our UI Design in Airtable service or contact us to talk through your audiences.