·
4 minute read
Every enterprise Airtable environment eventually stops being an island. The base that started clean and self-contained gets wired into a CRM, a billing platform, a support desk, a BI layer. And as those connections pile up, a hard truth sets in: some of them you can trust, and some of them are quietly corrupting your data. The unsettling part is that nothing in the vocabulary tells you which is which.
There's no official term that separates a sync you can rely on from one that's slowly poisoning your records. Both are just called a “sync.” A badly-built house is still a house, right up until the day it collapses. That missing vocabulary is exactly why so many teams can't see the problem coming, so let's define the thing that actually separates the two, because it comes down to a single rule most syncs never wrote down.
The Rule That Separates the Two: Ownership
A sync moves data between systems. That's the easy part, and it's the part everyone gets right. What separates a well-designed sync from a badly-designed one is whether anyone decided, explicitly, which system is authoritative for each field, and what happens when two systems try to write to that same field.
That's the whole game. A badly-designed sync just moves data and hopes. A well-designed one governs it: it knows what to do when two sources disagree, when the same customer record lives in three places with three slightly different values. Skip that rule and you haven't built a connection between two systems. You've pointed them at each other and walked away.
This is also the exact threshold that decides everything downstream: the point where a well-architected Airtable base stops being what determines whether your operation holds up, and the real question becomes whether the wider system landscape around it (the syncs, the ownership boundaries, the conflict rules) was designed with the same rigor. That's a question worth stepping back to look at in full.
What “Well-Designed” Actually Requires
When two systems can write the same field, a well-designed sync resolves the collision one of three ways, each a standard pattern from distributed data synchronization:
Last-write-wins. The most recent timestamp is the tiebreaker. Simple, but it silently discards the other edit, and it leans on clocks agreeing across systems.
A source-of-record hierarchy. One system is declared authoritative for that field, and its value always wins regardless of timing.
A reconciliation queue. When two systems disagree, the conflict is held for manual review instead of being auto-resolved. Slower, but the only safe option when a wrong value is expensive.
The point isn't which one you pick. It's that a badly-designed sync picks none, and picking none isn't neutral. It silently defaults to one as defined by the system's native rules, whether or not that's the rule your data actually needs.
One Worked Example: The Phone Number That Was Never Wrong
Take a field as boring as a customer's phone number. Your CRM owns it, and sales reps update it when they edit a contact. Airtable also holds it, because support agents update it during service calls. You've built a two-way sync so both stay current. Both directions run cleanly, every cycle completes, the error log is spotless.
Now the collision. Tuesday morning, a rep updates the number in the CRM. That afternoon, a support agent updates the same customer's number in Airtable to a different value. Nobody did anything wrong. Both writes committed. But nobody ever decided which system should win that collision, so the fallback rule decides for them: last one in wins. Whichever write happened to land second silently overwrites the other. Nothing errored, so nothing flags it. The customer now has one number in the system and no easy way to recover the one that got overwritten. The next person to find out is a rep who calls a dead line.
One constraint worth naming, because it's real: Airtable's native sync integrations are one-way by design. Data flows in, Airtable never writes back, which is exactly how the platform sidesteps this problem natively. The collision risk only appears once a team builds a custom two-way sync through the API or webhooks. At that point there's no built-in arbitration to inherit, because Airtable never offered two-way conflict handling in the first place. What happens when both sides edit the same record is entirely down to what that custom sync was built to do, which, if nobody defined a rule, is usually whatever the connecting tool does by default.
Field-level collisions are only the first way two systems disagree. A subtler failure happens one level down, when two systems can't even agree on which record they're pointing at, and a missed match quietly creates a duplicate instead of erroring. When your sync matches records by name instead of a stable ID, it doesn't just overwrite, it duplicates.
Why a Badly-Designed Sync Is So Hard to Catch
When enterprises audit their syncs, they audit the wrong thing. They check whether data is moving. They should be checking whether ownership is defined.
This failure mode is invisible by construction. A missing ownership rule produces no error and no alert. It produces plausible data: values that look correct because they are correct, just possibly stale ones from the losing side of a collision nobody arbitrated. You can't spot it by looking, because the corrupted record is identical to a healthy one.
So “how many syncs do you have?” is the wrong question. The better one: for how many of them can you name the system of record for every shared field, and say what happens when two systems disagree? Deciding who owns each field when Airtable isn't the only system writing to it is its own discipline. In most environments the honest answer is “not many,” and that gap is where trust in the data quietly dies.
A well-designed sync resolves any conflict based on well-defined rules the moment it happens. A badly-designed one can run without a single error for a year and still be broken the whole time. The failure was never in the connection. It was in the rule nobody wrote.
Stop Counting Syncs, Start Governing Them
Since the vocabulary won't warn you (a sync is a sync, whether it's sound or quietly rotting) the signal you have to check for yourself is whether every shared field has a defined owner and every collision has a defined resolution. That's the real line between a good sync and a bad one, and it's the line between a system you can trust under audit and one that's been lying to you since the day it was wired together.
Defining that ownership layer across a live, multi-system environment, without breaking the flows already running through it, is exactly what InAir does. We map every shared field to a system of record, encode the collision rules your syncs are missing, and turn a pile of connections into a governed architecture your operations can actually trust. Schedule a Discovery Call with InAir to turn sync sprawl into a system of record you can defend.