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.

Integration & reliability

Your data flows should make sense to the people who rely on them.

It started with…

CRM and ERP systems describe the same business differently. When the connection lives in an opaque script, a failed sync quickly becomes a call to its author.

So we built…

An Airtable control room for the sync engine. Operations can inspect jobs and run history; developers can review the underlying mappings. Both use the same configuration.

Technologies & official documentation

Take a look inside

Screen 1 of 6

Operations view

Operations view

Resolved names explain source, destination and write policy without hiding the mapping.

What we set out to change

Help teams understand what is synchronised, diagnose a failed run and adjust configured schedules without redeploying the engine.

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

The user journey

  1. 01

    Define the job and its mapping in the shared reference.

  2. 02

    Request or schedule execution through Airtable automation and the external worker.

  3. 03

    Inspect the run, its metrics and errors before deciding what to retry.

Base structure

Entity / tableKey fieldsRelationships
Sync JobsMapping JSON · schedule · enabled status · manual requestOne job → many recorded runs
Sync RunsStatus · read / written / skipped counts · diagnosticsEach execution links to its job
Sync TypesSource and configuration referencesShared definitions classify jobs
PromotionsMatching keys · mapped destination fieldsA common destination for operational reporting

Technical implementation

  • A TypeScript bridge runs the Python engine on Trigger.dev. Source adapters, mapping validation and destination writing are separate responsibilities.
  • The REST writer resolves field identifiers, groups writes into batches of 10 and includes rate limiting.
  • Preview/log-only support and read, written, skipped and error metrics make a run inspectable.

Engineering decision

Recompute the full series, write only changed cells

Adapted from the weekly-series writer. A complete recalculation can correct old periods, while a cell diff avoids rewriting unchanged values. Missing series are left untouched, an explicitly empty series clears previous counts, and dry-run is the default. This is repeatability for a normalised snapshot, not a distributed transaction or a concurrency lock.

Pythonweekly_diff.py32 lines
def plan_updates(series_by_record, existing, field_maps):    updates = []    for record_id, series in series_by_record.items():        desired = {}        for metric, week_fields in field_maps.items():            values = series.get(metric)            if values is None:                continue  # unavailable source: preserve this metric            for week, field_id in week_fields.items():                desired[field_id] = int(values.get(week, 0))        current = existing.get(record_id, {})        changed = {            field: value for field, value in desired.items()            if int(current.get(field) or 0) != value        }        if changed:            updates.append({"id": record_id, "fields": changed})    return updatesdef sync_series(series, existing, field_maps, batch_update, *, dry_run=True):    updates = plan_updates(series, existing, field_maps)    summary = {        "records": len(updates),        "cells": sum(len(row["fields"]) for row in updates),        "written": 0,    }    if not dry_run and updates:        # Injected adapter owns API batching and error reporting.        summary["written"] = batch_update(updates)    return summary

Adapted implementation excerpt

Recompute the full series, write only changed cells

Controls and boundaries

  • Credentials belong in the execution environment; a readable mapping does not need to contain their values.
  • Retries, quotas and matching rules must be evaluated per source. This case does not claim exactly-once delivery.

Who can contribute

  • Operations: inspect jobs, request runs and interpret execution history.
  • Builders: maintain permitted mappings and schedules in Airtable.
  • Developers: add adapters and test mapping or writer changes against the shared contract.

What supports this case

The live back-office was inspected in Human and Dev modes. The repository contains the mapping schema, engine and both released interface extensions. No synchronisation was triggered during review.

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