Most enterprise integration projects start with a brief that looks something like this:
Project: Connect the CRM to Airtable.
Scope: New and updated contacts in the CRM appear in the Airtable Accounts table.
Done when: A contact created or edited in the CRM shows up in Airtable with the correct field values.
Every line of that brief can be tested on the day the integration launches, and each test is likely to pass. That's the problem. The brief defines success as data arriving. It never asks which system's value is correct when two disagree, what happens to a bad record before it spreads, or who finds out when a write fails. A connection can meet every line of this brief and still produce wrong data for months.
Call that limit the connectivity ceiling: the point past which knowing that a connection works tells you nothing more about whether the data is right.
The brief above isn't careless. It's what the task naturally produces. "Connect these two systems" is a request about movement, and the obvious way to confirm movement is to watch data arrive. Nothing in the request raises ownership, conflicts, or failure routing, so nothing in the brief does either.
Testing reinforces it. Checking whether data arrives takes one test, and once it passes, it usually keeps passing. The problems that break integrations later, such as two systems editing the same record, a retry landing after a newer update, or a failed write nobody hears about, need specific conditions a launch-day test rarely creates. So the tests that are easy to run are the ones that pass, and the ones that would expose a problem usually never get run.
InAir's first pillar page names the underlying habit in its section on when "it works" is not good enough: a common anti-pattern in citizen development is optimizing exclusively for immediate functionality. An integration brief that only asks whether data moves applies the same habit to the connections between systems.
InAir's guide to running Airtable inside complex, high-volume system landscapes reduces the gap to a single test. Ask of any integration: if this connection works perfectly every single time, is the data correct?
For many connections, the honest answer is "not necessarily," because a write can succeed and still leave a wrong value behind. It can overwrite a newer value with an older one, create a duplicate when a match fails, or collide with a write from another system. The first two can happen even when only one system writes the data: a retry that arrives late or a match on a name instead of an ID is enough. Those mechanisms are covered in write collisions: what happens when two systems touch the same record at the same time. None of them shows up as a failed test, because in each case the connection did exactly what it was built to do.
The same guide asks five questions of any integration, which together make up what InAir calls the Orchestration Lens. Asked after launch, they're a diagnosis. Asked before, they become acceptance criteria: things the brief commits to and the team tests before the integration goes live.
1. Ownership is assigned. For every field more than one system can touch, the brief names the system that's authoritative for it. Evidence: a written rule per shared field. How to set this up is covered in Cross-System Source of Truth: who owns a field when Airtable isn't the only system writing to it.
2. Conflict and ordering rules are defined. When defining one system as always authoritative isn't enough, because multiple systems can legitimately hold the correct value, the field needs a rule to decide between competing writes. It can apply the newer write by the sending system's own timestamp (not the time the write reached Airtable) or by a sequence number, with a stated tiebreaker such as a fixed system priority, or it can hold the conflict for review. The same rule has to cope with writes that arrive out of order. Evidence: a written rule for each shared field, plus whatever applies it, such as a stored sender timestamp or sequence number that the integration compares before each write. Why ordering needs its own mechanism is covered in out-of-order updates.
3. Writes are validated before they propagate. The brief says what an incoming write is checked for (required fields present, linked records that exist, values in the expected range) and what happens to one that fails. Evidence: a staging state or holding table, and a named place where rejected writes go. How to build the check is covered in designing a validation script with structural checks and anomaly detection.
4. Failure is routed to a named person. When a write is rejected or an automation fails, the brief says which role hears about it and where. Evidence: a named owner and a backup, and a test showing the signal actually reaches them. That method is covered in alert ownership.
5. Blast radius is bounded. For each field the integration writes, the brief lists what that field feeds: automations that fire on it, records that recalculate from it, downstream syncs that pick it up. Evidence: the list itself, and a point where a bad value stops before it reaches all of them. How to trace this is covered in blast radius: tracing what one bad value actually touches in Airtable.
Here's the same project, with the five criteria built in:
Project: Connect the CRM to Airtable.
Scope: New and updated contacts in the CRM appear in the Airtable Accounts table. Records are matched on the CRM's contact ID, never on name or email.
Ownership: The CRM is authoritative for Name, Email and Phone. Airtable is authoritative for Account Tier and Fulfillment Status. The sync sends only CRM-owned fields, and support agents can't edit CRM-owned fields in Airtable.
Conflicts and ordering: Each write carries the CRM's last-modified timestamp, and Airtable stores the timestamp of the last write it applied to each record. A write with an older timestamp is rejected and logged.
Validation: Incoming writes land in a holding table first. A write missing Name or Email, or with an ID that doesn't match an existing record on an update, is held and flagged with the reason.
Failures: Rejected and held writes are logged to a failure table. The integration owner reviews it. The platform admin is the backup.
Blast radius: Phone feeds the SMS notification automation and the support desk sync. Both run only on records that have passed validation.
Done when:
The first line of "Done when" is the original brief. The rest are what move the integration from connectivity to orchestration. Each one is tested before launch, so the answer is known at build time instead of found months later, when a report looks wrong.
This matters because the decisions an integration depends on are easiest to make before anything is connected. InAir makes a similar argument about media operations in Why Media Integrations Fail Before They're Built: most media integration failures don't start with broken automations, but with systems that were never designed to carry decisions.
Not every connection needs the full brief. A one-way sync from a system that is genuinely the only writer of those fields has no second writer to conflict with, so the ownership and conflict rules between writers mostly fall away. Airtable's own sync integrations are always one-way, from the external app into Airtable, which is one reason they avoid conflicts between writers.
For a custom one-way integration, the rest of the brief still applies. Records still need to match on a stable ID, since a single writer can still create duplicates when it matches on a name, as covered in why your integrations create duplicates. A retry can still arrive after a newer update. And with any one-way sync, native or custom, a bad value from the source still flows in and travels wherever that field feeds, and a sync that stops still needs someone to notice. The one-way case shortens the brief. It doesn't reduce it to "it works."
Knowing which of your connections need which criteria is part of assessing a landscape's overall risk, the work InAir's Integration Load framework is built to do.
"It works" is a fair first test and a poor final one. It confirms that data moves, and stops there. The five criteria cover everything after that: which value is right, what happens when writes collide or arrive out of order, what gets checked before a write is trusted, who hears about a failure and how far a bad value travels. Written into the brief, they get answered while they're still cheap to answer.
If you have an integration project coming up, or one already running on a brief like the first one above, Schedule a Discovery Call with InAir to rewrite it around what the connection actually needs to guarantee.