Cross-System Source of Truth: Who Owns a Field When Airtable Isn't the Only System Writing to It

Most advice about a “single source of truth” quietly assumes you have one system. Inside a single well-designed Airtable base, that assumption holds, and the goal is clean: every fact lives in exactly one place, and everything else links back to it.

Then Airtable stops being the only system in the room. A CRM writes to the same customer record. A billing platform owns part of it. A support desk touches it during every service call. Now the phrase “single source of truth” starts to buckle, because there is no longer a single system that could plausibly hold it. Ask “which system is the source of truth for this customer?” and the honest answer is none of them, and all of them, depending on the field.

That's the whole problem this post is about. At enterprise scale, source of truth is not a system you pick. It's a decision you make one field at a time. And the reason that resolving ownership per field matters so much is that everything downstream, every sync, every report, every automated decision, inherits whatever ownership you did or didn't define here.

Source of Truth Was Never a Single-System Idea

There's a useful distinction from enterprise data architecture that clears most of the fog here. A system of record is the authoritative system for a specific data element: a CRM is the system of record for a customer's contact details, an ERP for financial records. A source of truth, in the strict sense, aggregates across those systems of record to give one consistent picture. As IBM frames it, the two are complementary but not the same thing.

The practical takeaway: in a multi-system environment, “source of truth” isn't a single throne one system sits on. It's a map. Every field has a system of record, and different fields can have different ones. The customer's phone number might be owned by the CRM. Their account status by the billing system. Their support tier by the help desk. Airtable might own the internal project link that none of the others even have a field for.

Once you see it as a per-field map instead of a per-system crown, the design task changes completely. You stop trying to crown one winner and start drawing boundaries.

The Ownership Map: One Writer Per Field

The core move is simple to state and hard to skip: for every field that more than one system can touch, name exactly one system as the writer. Everyone else reads.

This is the single-writer principle, and it's the cleanest defense against the silent collisions that corrupt multi-system data. If only the CRM writes the phone number, there is no scenario where the CRM and Airtable disagree about it, because Airtable was never allowed to write it in the first place. The conflict can't happen, because you removed the second writer.

In practice, an ownership map for a shared customer record might look like this:

Nothing about this is exotic. What makes it rare is that most teams never actually write it down. They wire the syncs first and let ownership emerge by accident, which is exactly when duplicate records and silent conflicts start accumulating. The map isn't a document you produce for its own sake. It's the thing that decides whether a collision is even possible.

When You Genuinely Can't Enforce a Single Writer

Single-writer is the goal, but honesty matters more than a tidy rule. Sometimes two systems really do both need to write the same field, for reasons the business won't let you engineer away. The phone-number case from real support workflows is the classic one: sales updates it in the CRM, and support genuinely needs to update it in Airtable during a live call, and you can't tell support to stop.

When you can't remove the second writer, you fall back to an explicit resolution rule, chosen deliberately rather than inherited by default. The standard options are the same three that exist anywhere two systems can write the same data:

Timestamp priority (last-write-wins). The most recent edit is the winner. Simple to implement, and defensible when the newest value genuinely is the most correct one, like a customer reading you their current number over the phone. Its known weakness: it silently discards the other edit, and it leans on clocks agreeing across systems, which isn't always safe.

A source-of-record hierarchy. One system is declared authoritative for that field, and its value wins regardless of timing. If the CRM is the declared owner of phone numbers, a support edit in Airtable is treated as provisional until the CRM confirms it. This is single-writer's more forgiving cousin: a second system can write, but only one gets to win.

A reconciliation queue. When two systems disagree, the conflict isn't auto-resolved at all. It's flagged and held for a human to decide. Slower, but the only safe option when a wrong value is expensive, and no automatic rule can be trusted to always pick right.

The point isn't that one of these is correct. It's that leaving the choice unmade doesn't avoid the decision. It just silently selects the first one, since last-write-wins is what you get by default when nothing arbitrates. Choosing none is choosing that one blindly.

Where Airtable Sits in This Map

Here's where the single-writer principle from earlier shows up as a platform default rather than a choice you make. When Airtable pulls data through its native sync, that sync is one-way by definition: the external system writes, Airtable reads. In other words, the platform has already applied the one-writer rule for you and put Airtable on the reading side of every synced field. That's the same lock described in the ownership map above, just enforced by Airtable instead of chosen by you, which is why a natively-synced field simply can't produce the kind of collision this whole post is about.

The picture flips the moment a team wires a custom two-way connection through the API or webhooks so Airtable's own edits flow back out. Airtable is now a genuine second writer, and every row of your ownership map suddenly carries weight it didn't before. This is the precise point where a harmless-looking sync turns into an integration with no ownership rule behind it, the difference that decides whether it fails loudly or silently, which is why Airtable's native sync integrations are often not sufficient when builders need data that can move in both directions. And the moment you build that two-way flow, the ownership map stops being paperwork; it becomes the only thing standing between two systems and a silent overwrite.

And field ownership is only half of identity. Even a perfect writer map fails if two systems can't agree on which record they're both writing to, which is a different failure with its own fix. Before you can decide who owns a field, both systems have to agree they're looking at the same record, and by name they often don't.

Draw the Map Before You Wire the Sync

Every shared field is a small ownership decision waiting to be made. Make it on purpose, once, and the collisions become impossible or at least arbitrated. Skip it, and the sync makes the decision for you, badly, in silence, every time two systems disagree.

Drawing that map across a live enterprise environment, deciding the system of record for every shared field and encoding the resolution rules for the ones you genuinely can't reduce to a single writer, is exactly what InAir does. We turn an implicit, accidental ownership model into an explicit one your whole operation can read and trust. Schedule a Discovery Call with InAir to map who owns what before your next sync decides it for you.