Omni is Airtable's AI assistant and app builder. Describe the app you want, and it creates the tables, fields, sample records, and an interface to go with them. For a first draft, it is the fastest way to get from an idea to something clickable that Airtable has ever shipped. For a production app, it is the start of the work, not the end. This guide walks through building a first app with Omni and then doing the hand-fixes that turn a demo into a base your team can live in.
Before you prompt
Omni is available from the Airtable home screen and inside bases on plans that include Airtable AI; if you do not see it, check your workspace plan and that AI features are enabled by your admin. Each Omni action consumes AI credits, so build in a sandbox workspace rather than a production one until you know what you are doing.
Spend five minutes writing down three things before you type a prompt:
- The nouns. What are the real-world things this app tracks? For a simple client-projects app: Clients, Projects, Tasks, People.
- The relationships. A client has many projects; a project has many tasks; a task has one assignee.
- The jobs. Who opens this app and what do they need to do in it? A project manager updating task status is a different page from an executive scanning project health.
Omni will do a reasonable job with a vague prompt. It does a much better job with a precise one, and the precision you add up front is precision you do not have to retrofit later.
Step 1: a prompt that describes the data model
A prompt that works well looks like this:
Build a client project tracker. Tables: Clients (name, industry, primary contact email), Projects (name, linked client, status as a single select of Proposed/Active/On hold/Done, start date, target end date, budget in USD), Tasks (name, linked project, assignee linked to a People table, status of To do/Doing/Done, due date, estimate in hours), People (name, email, role). Add an interface with a dashboard of active projects by status, and a task page for assignees.
Notice what the prompt does: names every table, names every field, says which fields are links, and fixes the select options. You have effectively handed Omni a schema. That is the single biggest lever on output quality.
Run it. Omni creates the base, populates a handful of sample records, and generates an interface. Open every table and every interface page and just look before you change anything.
Step 2: what Omni usually gets right
In our experience across many client builds, Omni reliably produces:
- Correct table-per-noun structure when the prompt names the tables.
- Linked-record fields in the direction you asked for, with the reverse link auto-created.
- Sensible field types for dates, currency, and emails.
- A usable interface skeleton with a dashboard page and a record list page.
If the prompt was precise, you will rarely have to change the table structure.
Step 3: what to fix by hand
This is where the real work is. Go through the following in order.
Naming
Omni tends to produce either overly generic names ("Name", "Status", "Notes" in every table) or oddly verbose ones. Rename primary fields so they are unambiguous in a lookup: Project name, Task name, Client name. A linked-record field named Client on Projects and Projects on Clients reads correctly in both directions; check every reverse link and rename it.
Select-field hygiene
Open every single-select and multiple-select field. Omni sometimes adds options from the sample data it invented, so you will find stray values such as "In progress" alongside your "Doing". Delete anything you did not ask for, put the options in workflow order, and colour them consistently (the same colour for "Done" everywhere). Every select option you leave in is an option someone will eventually pick.
Linked records, not text
Look for any text field that holds the name of something that lives in another table. "Assignee" as a text field instead of a link to People is the classic one. Convert it: Airtable's field-type change to a linked record will match existing names against the target table and create links. Check the result.
Lookups and rollups
Omni rarely adds the derived fields that make a base useful. Add them now:
- On Projects: a rollup of
Estimatefrom Tasks (SUM(values)), a count of open tasks using a conditional rollup, and a lookup ofPrimary contact emailfrom Clients. - On Tasks: a lookup of
Client namethrough Projects, so the task page can be filtered by client.
Sample data
Delete it. All of it. Sample records that survive into production end up in reports, and one fake client in a pipeline rollup is enough to make a manager stop trusting the dashboard.
Views
Omni creates a default grid per table. Add the working views your team will use: Tasks grouped by assignee and filtered to not-done, Projects filtered to Active and sorted by target end date. Name views by audience and purpose, for example PM – open tasks by owner.
The interface
The generated interface is a starting point. Remove fields nobody needs on each page, rename element labels into plain language, set the page filters (an "Active projects" dashboard should actually filter to Active), and configure permissions so assignees can edit task status but not budgets. If you are going to share the interface with people who should not see the base, set it up as interface-only access now. Our Interface Designer guide covers this in depth.
Step 4: a quick QA pass
Before inviting anyone, run this checklist:
- Create one real client, one real project, three real tasks through the interface, not the grid. Does every field you expected to be required behave that way?
- Open the dashboard. Do the numbers match what you just entered?
- Log in as a test user with the lowest permission level and try to break something: edit a budget, delete a project, open a table they should not see.
- Check the reverse links one more time. A task accidentally linked to two projects is a data-integrity problem that no dashboard will reveal.
When to start from a template instead
Omni is the right tool when your data model is a little unusual, when you can describe it precisely, and when you want an interface generated alongside it. It is the wrong tool when a well-made template already exists for your use case; Airtable's template gallery and Universe have mature content calendars, CRMs, and product roadmaps that have been refined by thousands of users. Start from the template, then use Omni inside the base for additions ("add a table for vendors linked to projects") rather than for the whole thing.
It is also the wrong tool for migrating an existing dataset. If you have a spreadsheet or a legacy database with real records, design the schema to fit the data you actually have; see our data migration service for how we approach that.
Summary
Write the schema into the prompt. Accept the tables, fix the names, clean the selects, convert text to links, add the derived fields, delete the sample data, and reshape the interface for each audience. Budget roughly the same time for the hand-fixes as you saved on the build. Done that way, Omni gets a small team from nothing to a trustworthy app in an afternoon.
If you would rather have someone who has done this many times review your Omni build before it goes live, contact BaseBrainers or read about our Airtable AI and Omni consulting.