In a recent joint session for the Airtable Media & Entertainment and ANZ User Groups, our co-founder Nathan Coffey built a working custom interface for campaign management live, using Claude and a couple of Airtable-specific tools. Here’s the business case, the walkthrough, and everything you need to try it yourself.
- Campaign data in Airtable is often spread across many tables, which makes a simple “where does this stand” question hard to answer.
- A custom interface pulls this data into one view, and you can build a different view for every stakeholder.
- It’s a faster, lower-risk win than a full AI rollout, layering on top of a base you already trust.
- You can build one with Claude and an Airtable-specific reference doc, no code written by hand. Steps, gotchas, and the recording are all below.
Prefer to watch? The full session recording is on Airtable’s site, or read on for the write-up.
The problem
Most media and creative ops teams run their campaigns in Airtable, and for good reason. But the data that makes a campaign run well almost always lives split across several tables:
- Phases and deliverables
- Review cycles
- PTO and holidays
- Industry beats
That’s great for the people working in the base day to day. It’s much harder for the people who need a step back: a VP checking overall health, a client wanting a status update, a vendor who opens Airtable twice a year.
Airtable’s native views are excellent within a table. They start to strain when a decision depends on five tables at once.
That’s exactly the gap custom interfaces close, and they’re a much faster win than a full AI rollout. AI features are valuable, but rolling them out well takes process change and buy-in across a team. A custom interface can go live on top of a base you already trust, in days, without touching how anyone works day to day.
The key shifts
Pull dates from multiple tables into one timeline
Instead of checking five separate tables to answer “where does this campaign stand,” a custom interface pulls dates from all of them into a single timeline, so the answer lives in one view.
In the session, this took the shape of a portfolio view that also worked backward from a fixed premiere date, so every milestone automatically lined up ahead of launch.
Ship custom interfaces before a big AI rollout, and build a view for every stakeholder
Custom interfaces are a quicker, lower-risk win than a full AI transformation, and they pay off immediately because different people need different things from the same base. A VP wants a portfolio view. A vendor wants something that looks like the tools they already use, not “the Airtable version” of a content calendar. Once your data is solid, custom interfaces let you build the right lens for each audience without duplicating your base.
You don't need an engineering team to build one
Feed an AI tool like Claude an Airtable-specific reference doc plus your base’s schema, and it can generate paste-ready code for Airtable’s interface editor, no code written by hand. It’s accessible even if you’re not technical. It’s also not perfectly smooth on the first try, and there are a few real gotchas worth knowing before you attempt this yourself, covered in the next section.
In the session, this is exactly how Nathan built his interface live: prompts, a reference doc, and some back-and-forth troubleshooting, nothing hand-coded.
Keep your base clean, not just your views
Here’s a less obvious unlock: because the interface does the assembling, you stop piling rollups, lookups, and complex formula fields onto the underlying tables just to report on them. That means less complexity in the data layer, and a base that’s far easier to maintain over time.
In the session, Nathan pointed out that the demo base had very few of those fields, and asked the room who’s wrestling with a single table that has 200 to 500 fields. That kind of sprawl is exactly what custom interfaces help you avoid.
That’s exactly the gap custom interfaces close, and they’re a much faster win than a full AI rollout. AI features are valuable, but rolling them out well takes process change and buy-in across a team. A custom interface can go live on top of a base you already trust, in days, without touching how anyone works day to day.
NATHAN COFFEY, CO-FOUNDER
How to build one, step by step.
Here’s the process Nathan walked through live
- Set up a Claude project. Give it a clear role: something like “you are a custom Airtable interface building service, working on campaign management and creative ops use cases, using industry and Airtable UI best practices, and outputting React code we can paste into Airtable.”
- Feed it Airtable’s interface skill doc. This is a reference document built by Victoria Plummer at Airtable that teaches an AI tool the specific nuances of writing Airtable custom interface code. Add it as a project file so Claude references it every time. Grab the interface toolkit repo.
- Give it your base’s schema. Claude needs to know your tables and fields before it can build anything useful. If you don’t have Airtable’s MCP available yet, a simple scripting extension can export your table and field structure so you can paste it straight into Claude as plain text. Grab Nathan’s schema-export script.
- Prompt for the actual interface you want. Be specific about what should show, at what level of detail, and what a user should be able to drill into. The more context you give it here, the fewer rounds of back and forth you’ll need.
- Create a blank custom interface element in Airtable using Omni first. New Interface, describe something simple, let Omni generate a starting element. This gives you a canvas to paste real code into.
- Open the source code editor and paste Claude’s code in. Find the three-dot menu on your interface element, choose edit source code, paste, and save.
- Debug, then iterate. You’ll likely hit an error or two. Paste it straight back into Claude, or take a screenshot and describe what’s off. Repeat until it looks right.
If Claude’s code references a field that Airtable says “doesn’t exist,” check whether that field is set to visible in the interface first. This is rarely a code problem, it’s almost always a visibility setting, and it’s easy to burn hours chasing the wrong thing.
Paste your schema in as plain text rather than a PDF. PDFs introduced parsing errors and ambiguity that plain text didn’t.
Custom interfaces currently can’t combine data across multiple bases, only multiple tables within one base. If your data spans bases, you’ll need to sync it into one first.
Sometimes Claude defaults to a fully coded, technical build. If that happens, just redirect it: tell it you only need the React code to paste into Airtable’s editor.
It’s also worth knowing Claude isn’t the only way in. Omni and HyperAgent (Airtable’s own AI agent, already loaded with Airtable’s best practices) can build custom interfaces too, and are worth trying for simpler use cases.
The same approach also works with other AI tools, or you can hand the code off to an engineering team if you’d rather not build it yourself.
FAQ
Who typically builds these interfaces, the end users or a consultant?
There’s no single right answer, but the key is a central solution owner, or a small ownership team, with both Airtable expertise and a real understanding of the business. User feedback flows to that owner, who prioritises what gets built, then either a business user with the right Airtable chops builds it or you bring in a consultant. Fewer cooks in the kitchen keeps the result simpler.
Can a custom interface pull data across multiple Airtable bases?
Not yet. Custom interfaces work across multiple tables within one base, but not across bases. If your data spans several bases, you’ll need to sync it into one first.
Is Claude the only tool that can do this?
No. Omni (Airtable’s in-house builder) can do it too, it just takes a bit more back and forth, and Airtable is improving it fast. You can follow the same technique with OpenAI, Google, or any other AI tool, use HyperAgent (Airtable’s own agent, already loaded with Airtable best practices), or hand the code to a team of engineers.
In the session, this is exactly how Nathan built his interface live: prompts, a reference doc, and some back-and-forth troubleshooting, nothing hand-coded.
How detailed should the prompt be?
More detailed than you might think. Nathan kept the live prompts deliberately simple to move fast, but his advice was to give the project real context: your role, your responsibilities, what matters to your business, and where you feel the gaps are. The more you seed up front, the fewer rounds of back and forth you’ll need.
Try it yourself
Recording: Watch the full session — the complete live build, start to finish
RePO: Airtable interface toolkit — the reference doc used to teach Claude the ins and outs of custom interfaces
SCRIPT: Schema-export script — pulls your base structure into plain text for Claude
Nathan Coffey is a co-founder at Nifty. He found Airtable in 2018, back when the product was, in his words, “literally just a database.” He spent the years after that consulting at Airtable, delivering a couple of hundred builds, almost all of them in media. He now does that work as an external partner, building on Airtable and standing up the internal teams who run it across large, cross-functional organisations. Connect with him on LinkedIn.
Nifty is the Airtable transformation partner for media companies. We are a Gold-certified Airtable partner, top-rated globally, trusted by Netflix, Disney, CBS, Paramount and Yahoo.
What's next
If this was useful, there’s more where it came from:
- Follow Nifty on LinkedIn for ongoing Airtable tips and builds
- Join the Airtable Media & Entertainment User Group to catch the next live session
- Talk to Nifty if you want to work through your own Airtable setup
