---
title: 'How to Build Custom Interfaces with Airtable Omni'
description: 'Step-by-step guide to building Airtable interfaces with Omni — prompting strategies, iterative refinement, what Omni builds well, and production-readiness checklist.'
canonical_url: 'https://www.business-automated.com/tutorials/build-interfaces-with-airtable-omni'
md_url: 'https://www.business-automated.com/tutorials/build-interfaces-with-airtable-omni.md'
last_updated: 2026-04-19
---

[Airtable](/airtable-consultant) interfaces used to take a day. The ones we ship to clients today — with proper filtering, record detail panels, and dashboard charts — take the same time they always did if you build them from scratch. But with [Omni](/tutorials/what-is-airtable-omni), you can get to a 70% draft in five minutes and spend the rest of your time polishing.

This is the hands-on guide to actually doing that. It covers how to prompt Omni so you get what you wanted the first time, how to refine iteratively when the first pass misses the mark, what Omni nails out of the gate, and the pre-ship checklist we run on every Omni-built interface before a client sees it.

If you're not yet familiar with Omni itself, start with [What Is Airtable Omni](/tutorials/what-is-airtable-omni) for the platform-level overview.

## Step 1: Have Your Data Model Ready

Omni builds interfaces from data that already exists. Before you open the chat, make sure:

- **Your tables and fields are set up** — Omni can only surface fields that exist. If you want a "deal value by region" chart, there needs to be a Deals table with a Value field and a Region field.
- **Key calculations exist as formula or rollup fields** — if your dashboard needs "average days to close," create the formula first. Omni can reference it but often can't invent the calculation itself.
- **Records have real data in them** — at least ten to twenty rows per table. Interfaces that look great with real data look broken with three test rows.

Five minutes of data prep makes Omni dramatically more useful. Skipping this step is the single most common reason first-time Omni users are disappointed.

## Step 2: Write a Specific, Audience-Focused Prompt

The biggest determinant of Omni output quality is the prompt you give it. Vague prompts produce generic, forgettable interfaces. Specific prompts produce interfaces you actually want to ship.

**A bad prompt:**

> Build a dashboard for my CRM.

**A good prompt:**

> Build an executive dashboard for my CRM that shows, at the top, three summary numbers: total open pipeline value, deals closed this month, and average deal size. Below that, a bar chart of pipeline by stage, a line chart of deals closed per month over the last six months, and a filtered list of the top 10 deals by value. Add a filter for deal owner at the top of the page so I can view the dashboard for any rep.

Three ingredients separate the two:

1. **The audience** ("executive dashboard," "for my sales reps") — tells Omni whose perspective to take.
2. **Specific components with specific data** ("three summary numbers: open pipeline value, deals closed this month, average deal size") — eliminates guessing.
3. **Interaction model** ("filter by deal owner at the top") — defines what the user will do with the interface.

When we're building interfaces for clients, we often write the prompt as a short spec first, then paste it into Omni. The prompt becomes a byproduct of thinking clearly about what we want.

## Step 3: Refine, Don't Restart

The first pass will miss things. That's fine and expected — the right move is to refine, not start over. Omni keeps the interface and the conversation context, so follow-up prompts work on top of what already exists.

Effective refinement prompts are small, specific, and one-at-a-time:

- "Change the bar chart to a line chart."
- "Add a color filter by deal stage."
- "Move the summary numbers to the top right."
- "Make the list show only deals in 'Negotiation' stage."
- "Hide the Owner field from the record detail view."

Bad refinement prompts are vague or combine too many changes at once:

- "Make it better." (Better how?)
- "Rearrange everything and also add a tasks section and change the color scheme." (Too many things — Omni may partially execute and you'll lose track of what changed.)

**The rhythm we use:** one concrete change per prompt, check the result, next change. It feels slow the first time, but the total time to a finished interface is shorter than restarting or trying to batch a dozen fixes into one mega-prompt.

## Step 4: Know What Omni Nails and What It Misses

After dozens of Omni-built interfaces, the patterns are clear.

**Omni is strong at:**

- **Charts from clear metrics.** "Bar chart of revenue by month" works first time almost always.
- **Summary number blocks.** Perfect for executive dashboards — pick the three numbers that matter and Omni lays them out cleanly.
- **List layouts with filtering.** "A list of all open deals, grouped by stage, sorted by value descending" is exactly the sort of prompt Omni handles well.
- **Record detail panels.** "When I click a contact, show me their info, their linked companies, and their recent activity" produces a usable detail view.
- **Multi-page interfaces.** Omni can set up a navigation sidebar and multiple pages from a single prompt if you describe them.

**Omni is weaker at:**

- **Pixel-perfect layouts.** If you care about exact spacing, alignment, and proportions, plan to finish manually.
- **Custom color palettes and branding.** Omni picks defaults that are fine but generic.
- **Advanced conditional visibility.** Hiding components based on user role or record state often needs manual configuration.
- **Unusual chart configurations.** Stacked bar charts with specific groupings, charts with two axes, or charts with custom formatting may need tweaks in the Interface Designer.
- **Complex permission overlays.** Row-level security, user-scoped filters, and shared-view sandboxing all need manual review.

The mental model: **Omni builds the skeleton. A human finishes the polish.**

## Step 5: Run the Production-Readiness Checklist

Before you share the interface with a client or a team, run this checklist. It takes ten minutes and prevents the most common embarrassments.

**Data correctness:**

- [ ] Every chart, number, and list shows the data you intended (not all records, not a subset by accident).
- [ ] Filters are pre-set to the right defaults for the target audience.
- [ ] Grouping and sorting match how a real user would want to scan the information.
- [ ] Linked-record displays show useful fields (name, status, date — not just an opaque record ID).

**Layout and UX:**

- [ ] Component sizes are reasonable. Nothing is tiny or overflowing.
- [ ] The most important information is in the top half of the first screen.
- [ ] Mobile layout works — open the interface on your phone and click around.
- [ ] Click-through navigation works as expected (record detail from list, back button, etc.).

**Permissions and sharing:**

- [ ] Interface is shared with the right users or user groups.
- [ ] Field-level permissions hide anything the audience shouldn't see.
- [ ] If external users will see it, test with a private browsing session.
- [ ] View filters don't accidentally expose more data than intended.

**Copy and polish:**

- [ ] Page titles and component labels are in plain English, not technical field names.
- [ ] Empty states show something sensible if there's no data yet.
- [ ] The interface has a clear "what is this and what do I do here?" signal for first-time users.

Checking these takes a fraction of the time of building the interface — and skipping them is how Omni-built bases end up with "oh, we didn't realize clients could see that" moments.

## Example: From Prompt to Production in 45 Minutes

A real example from a recent client engagement (details anonymized). The ask was a weekly client reporting dashboard for a marketing agency — campaigns, spend, leads generated, and cost-per-lead, all filterable by client.

**Prompt 1 (scaffold, ~2 minutes):**

> Build a client reporting dashboard for a marketing agency. Top of the page: a filter to pick a client. Below that, four summary numbers — total ad spend this month, total leads generated, average cost per lead, and number of active campaigns. Then a bar chart of spend by campaign, and a list of the top 10 leads this month sorted by recency. Below the list, a line chart of leads per day over the last 30 days.

Omni built the whole thing. Charts showed data. Filter worked. List was populated.

**Refinements (about 15 minutes):**

- "Make the cost per lead number format as currency."
- "Change the leads list to show name, email, campaign, and created date."
- "Add a second chart below the spend chart showing leads by campaign."
- "Move the client filter to a sticky sidebar instead of the top."
- "Rename 'Ad Spend' to 'Media Investment' across the interface."

**Manual polish (about 25 minutes):**

- Tightened column widths in the leads list.
- Set up conditional coloring on cost-per-lead (green under $50, yellow $50–$100, red over $100).
- Added a custom page title and brand color to the navigation.
- Set up shared-view permissions so each client sees only their own data.
- Tested the mobile layout and reshuffled two components.

**Total: about 42 minutes.** Pre-Omni, the same interface would have taken two to three hours.

## When to Skip Omni and Build Manually

Omni isn't always the right tool. Skip it and go straight to the Interface Designer when:

- The interface is a small tweak to an existing one — editing three components manually is faster than re-prompting.
- You need highly customized conditional visibility or permission rules.
- The interface is part of a design system with strict brand guidelines.
- You're working in a base where the schema is still evolving and an AI-built interface would lock in decisions you're about to reverse.

For everything else — and that's most interfaces — Omni is now the default starting point in our workflow.

## The Bigger Picture

Omni's impact on interface work isn't that it replaces Airtable consultants. It's that it collapses the boring 70% (setup, initial layout, component placement) so that we can spend more of our time on the interesting 30% (the business logic, the edge cases, the polish that makes a dashboard feel like it was built for your specific team).

The clients we work with at [Business Automated](/airtable-consultant) don't want to pay us to click-and-drag components into place. They want to pay us to think about their business, design the right system, and ship it into production. Omni helps us give them more of that and less of the grunt work.

If you want help building a real Airtable interface with Omni — or auditing one you've already built to see what's missing — [get in touch](/airtable-consultant). We'll walk you through a prompt-to-production example on your actual data.


## Sitemap

See the full [sitemap](/sitemap.md) for all pages.