Our Airtable expertise

Your team knows the work. Let them shape the tools.

A purchasing review. A recruitment campaign. A process that has outgrown its spreadsheet. We turn that everyday work into an Airtable tool your team can make its own.

These examples draw on Julien Cyr’s four years building and evolving tools at Actual Group, including work for Actual Académie, ESUP, Holberton, iconoclass, Qwally, Open Campus and PBA. That experience informs Ownward’s work today.

Why we believe in Airtable

One foundation. More possibilities. Shared data · Team workspace · Connected site

The more people can contribute, the more the data structure matters. Airtable makes it tangible: tables, field types and linked records. A new view, interface or automation can use the same foundation. Teams have room to build without starting a separate data model every time.

That is the balance we help you get right: freedom for your builders, with shared definitions, appropriate permissions and clear rules for change. Airtable can support ERP-style workflows and a tailored CRM. We define what it owns and what stays in specialist systems, including accounting.

Omni + Ownward

Build with Omni. Go further with Ownward.

Omni is a great reason to choose Airtable. Describe what you need, build an app, create custom interface elements and work with your data in plain language. It gives your team more room to build and improve its own tools.

Ownward helps you take that freedom further when the work calls for deeper product and engineering expertise. We build on what your team has already created with Omni, connect it to the wider business and help you keep improving it over time.

  • An interface that fits the work

    Custom components, precise business rules and guided onboarding, refined with the people who use them.

  • A connected, shared data model

    Airtable, your CRM, accounting and website: clear ownership of each record, with integrations designed to handle exceptions.

  • The confidence to keep evolving

    Permissions, tests, versioned code and documentation for people and agents. Your team keeps building; we support the complex changes.

Explore Omni in Airtable

From the field

Start with a real piece of work.

Choose a story. See the need, visit the tool, then explore how it was built.

Shared data & publishing

The business database becomes the website’s source, too.

It started with…

Operations needs to maintain programmes, campuses and intakes in a consistent model that other products can reuse. The first responsibility is the quality and meaning of the source data.

So we built…

A shared Airtable reference, with linked entities and explicit field mappings for downstream use. This example focuses on preserving source relationships as the catalogue evolves; the linked web example covers publication.

Technologies & official documentation

One reference, several uses
  1. Airtable

    Maintain

    Business model and relationships

  2. Supabase

    Prepare for publishing

    Selected fields, statuses and media

  3. Vercel

    Serve the website

    Next.js reads the publishable catalogue

This documented flow uses a dedicated synchronisation engine. Zapier can coordinate other events; it does not replace that engine in this case.

Take a look inside

Screen 1 of 6

1. Maintain the offer

1. Maintain the offer

The internal catalogue uses linked programmes and campuses.

What we set out to change

Give operations one maintainable reference whose relationships remain reliable when other systems read it.

How it is builtData model, code, controls and team ownership

The user journey

  1. 01

    Maintain programmes and their linked campuses.

  2. 02

    Read the selected source fields and distinguish missing data from read errors.

  3. 03

    Preserve valid relationships for downstream consumers.

Base structure

Entity / tableKey fieldsRelationships
ProgrammesTitle · pathway · descriptionLinked campuses and intakes
IntakesPeriod · programme · campusConnect the offer to locations

Technical implementation

  • Source entities and relationships have stable identifiers.
  • Mappings make the fields shared with downstream products explicit.
  • A failed relationship read must not become an instruction to clear existing links.

Engineering decision

A failed read must not erase catalogue relationships

Adapted from the synchronisation guard for programme/category links. A failed source read omits the relationship column; a trusted empty link may clear it. If all links disappear while the publishing database still has relationships, the run preserves them and reports a warning. Renamed entities and an injected database probe keep this excerpt independent of private schema identifiers.

TypeScriptpreserve-catalogue-links.ts31 lines
type LinkRead =  | { ok: false; reason: "unconfigured" | "read-error" }  | { ok: true; links: Map<string, string | null> };export async function catalogueLinkPolicy(  source: LinkRead,  destinationIds: Map<string, string>,  hasPublishedRelationships: () => Promise<boolean>,) {  let trusted = source.ok;  if (source.ok && destinationIds.size > 0 &&      ![...source.links.values()].some(Boolean)) {    try {      trusted = !(await hasPublishedRelationships());    } catch {      trusted = false; // unable to verify: preserve the previous links    }  }  return {    warning: trusted ? null : "Relationships preserved; inspect source mapping",    fieldsFor(sourceId: string): { category_id?: string | null } {      if (!trusted || !source.ok) return {}; // omit, do not write null      const linkedId = source.links.get(sourceId) ?? null;      return {        category_id: linkedId ? destinationIds.get(linkedId) ?? null : null,      };    },  };}// Merge fieldsFor(id) into an allowlisted upsert row keyed by airtable_id.// Source reading and category synchronisation must complete beforehand.

Adapted implementation excerpt

A failed read must not erase catalogue relationships

Controls and boundaries

  • The browser receives no Airtable token or privileged Supabase key.
  • Internal fields and staff data are outside the public catalogue.
  • Synchronisation is not publication: permissions, statuses and publishing filters have distinct roles.

Who can contribute

  • Operations: maintain programmes, campuses and Airtable links.
  • Communications: enrich and approve publication in the web back office.
  • Developers: evolve mappings, checks and versioned components.

What supports this case

Source model and synchronisation guard reviewed. This capture shows the internal catalogue; the web journey is presented in the linked Vercel / Supabase implementation.

Working with Ownward

Built together. Then yours to grow.

Your team should be able to handle everyday changes. And know who to call when a problem needs deeper technical expertise.

  1. 01

    Start with the work

    We sit down with the people who do it, agree on what a useful first version looks like, and build the data model and interface together.

  2. 02

    Learn on your own tools

    Your team learns to adapt views, interfaces and automations on real tasks. We document the model and decisions so the next change does not depend on us.

  3. 03

    Go further, with support

    Citizen developers, developers and colleagues coding with Claude can contribute to the same documented model. We support complex integrations, code reviews and technical escalation as your needs evolve.

The details that make a delivery useful

The tool, and what your team needs to own it.

Our Ownward delivery standard: guidance stays inside the product, knowledge stays with the code, and coding agents have the context to contribute.

  • An onboarding wizard you can always reopen

    A guided path through roles, essential setup and the first useful action. It remains available from Help, including when a new colleague joins.

  • Documentation in the delivery repository

    Getting started, data model, configuration, integrations, tests, release and rollback: the explanations evolve with the product version. Secrets stay outside the repository.

  • Instructions for coding agents

    AGENTS.md and, where useful, CLAUDE.md describe the architecture, conventions, checks and change rules. An agent extends the shared model; the team retains review and release decisions.

See guided onboarding in a real interface
Where Builder Hub, custom components and AI fit

We build and release custom interface extensions when teams need a more focused experience. We help organise ownership, versioning and updates in Builder Hub. For Enterprise Scale organisations, managed apps and components offer a separate way to distribute shared building blocks across bases.

We use AI where it helps a defined task, with the relevant data access and human review. Enterprise features and their availability depend on your Airtable plan; we help you choose and configure what the team actually needs.

Which part of your work could be easier?

Bring the process, the friction or the idea. We can start there.

Talk about your project