·
5 minute read
"How many integrations is too many?" is a question enterprise teams often ask about Airtable, and it rarely has a useful answer. A landscape with two connected systems can be fragile, and one with five can be stable. The number of systems tells you how much exposure exists. It doesn't tell you whether any of that exposure is being managed.
This post explains why system count is the wrong measure of integration risk on its own, what actually decides whether a landscape holds up, and how to tell which kind of landscape you have. System count is one of the five factors in InAir's Integration Load framework, and the two-landscape comparison below first appears in InAir's guide to operating Airtable inside complex system landscapes.
Why Teams Count Systems in the First Place
Counting is the obvious place to start, and it isn't wrong. System count is easy to see, it goes up as a landscape grows, and it does track something real.
Every direction data can flow between two systems is a place where an assumption about shared data has to hold. In a peer-to-peer setup, where systems connect directly to each other, the number of one-directional connections grows as N × (N−1): five systems means up to twenty, and ten means up to ninety. InAir traces that curve in The Danger of Integration Glue, along with the alternative: routing systems through a central hub, which keeps the growth linear.
More systems also means more traffic against the same ceiling. Airtable limits the API to 5 requests per second per base, and every system calling the API draws from that one number.
So system count matters. The mistake is treating it as the answer rather than as a starting point.
What System Count Tells You, and What It Doesn't
System count sets exposure: how many places an assumption about shared data could be wrong. It says nothing about whether any of those assumptions actually are wrong, or whether anyone would notice if they were.
That second question is answered by other factors:
- Ownership: whether each shared field has a named authoritative system.
- Validation: whether incoming writes are checked before anything relies on them.
- Failure visibility: whether a disagreement or a failed write surfaces somewhere someone will see it.
- Update frequency and scope: whether syncs push only records that changed, or rewrite every record on every run.
A landscape where those are handled can absorb a lot of exposure. A landscape where they aren't can fail with very little.
Square Footage Versus Wiring
A building is a useful comparison. Square footage is a fair measure of how much area could catch fire. A bigger building has more rooms, more outlets, more places for something to go wrong. But square footage doesn't tell you whether anything will burn. The wiring does.
A large building with sound wiring, breakers on every circuit and working smoke detectors is safer than a small one with frayed wires and no alarms. System count is the square footage. Ownership, validation, sync scope and failure visibility are the wiring.
Two Landscapes, Worked Through
The difference shows up most clearly when the same everyday events hit two different landscapes.
Landscape A has two systems: a CRM and Airtable. Nobody has written down which system owns the customer phone number. Every few minutes, the CRM rewrites every customer record in Airtable, whether or not anything changed. Incoming writes land directly in the production table, and nothing compares the two systems' values.
Landscape B has five systems: a CRM, a billing platform, a support desk, a BI tool and Airtable. Every shared field has a named authoritative system. Syncs push only records that changed since the last run. Incoming writes land in a holding table and pass a validation check before reaching production. A scheduled job compares key fields across systems and logs any mismatch for review.
Event 1: A support agent updates a phone number in Airtable
In Landscape A, the agent's edit saves normally. Within minutes, the CRM's next write replaces it with the old value the CRM still holds. No error appears anywhere. The agent believes the number is updated, but it isn't, and the first sign may be a call that doesn't go through.
In Landscape B, the CRM owns the phone number, so support agents can't edit it in Airtable. The agent updates it in the CRM, and the change reaches Airtable on the next sync. One way to enforce this is Airtable's field editing permissions, available on Team, Business, and Enterprise Scale plans, which apply to edits made through the API as well as in the interface. The conflict never happens because only one system writes the field.
Event 2: the CRM sends a record missing a field the base depends on
In Landscape A, the record lands straight in production with the field blank. Automations and reports that read the table treat it like any other record. The gap surfaces only when something downstream breaks or a person spots it.
In Landscape B, the record lands in the holding table first. The validation check finds the missing field, flags the record with the reason and keeps it out of production until someone fixes it. InAir built the base-to-base version of this check as the Schema Validation Gate in Enforcing Data Contracts in Airtable.
Event 3: two systems end up holding different values for the same field
In Landscape A, nothing compares the CRM and Airtable, so the difference sits there until a report, a customer or an auditor exposes it.
In Landscape B, the scheduled comparison finds the mismatch and logs it for review the next time it runs. The divergence becomes a visible item with a date on it, instead of something discovered months later. That mechanism is covered in building a cross-system agreement check.
Across all three events, Landscape B has more than twice the systems and still comes out ahead. Nothing about Landscape B made its systems less likely to send bad data. What changed is that each problem either couldn't happen or got caught.
Why Fewer Integrations Isn't a Safety Guarantee
Small landscapes often skip governance because it feels unnecessary. With two systems, it seems obvious which one is right, and building a holding table for one integration can look like overkill. But in Landscape A, the obviousness is exactly the problem. Nobody wrote the rule down, so nothing enforces it.
The same applies to consolidation. Cutting a landscape from six integrations to three reduces exposure, and that has real value. But if the three that remain still have no ownership rules, no validation and no failure visibility, the landscape has fewer places to fail and no better way of noticing when it does.
Why More Integrations Can Still Be Safe
The opposite is also true, within limits. InAir's position in Best-of-Breed Integration Strategy: Avoiding the All-in-One Trap is that Airtable often works best as an orchestration and intake layer, with specialized tools handling what they're built for. That means more connected systems, and in a governed landscape that's manageable. A new system gets an ownership assignment for every field it touches, its writes go through the same validation gate, and its connection is added to whatever detects disagreement.
That doesn't make system count irrelevant. Every added system is more to govern, more traffic against the same rate limit, and more to reassess over time. The point is narrower: a higher count doesn't mean higher risk when the wiring is sound, and a lower count doesn't mean lower risk when it isn't.
How to Tell Which Landscape You Have
Five questions will place a landscape closer to A or B, whatever its size:
- Can you point to a written record of which system is authoritative for every shared field? A Slack thread or someone's memory doesn't count. The full model is in this post. Cross-System Source of Truth: who owns a field when Airtable isn't the only system writing to it.
- Do incoming writes pass through a staging state before they reach production tables?
- Do syncs push only records that changed, or rewrite every record on every run?
- If two systems disagreed about a field right now, what would surface it, and who would see it? A commit status and a failure table are one answer, documented here.
- Do you have a current list of every token and webhook connected to each base? Build it from access records, not from memory.
Questions 1 and 4 matter most. They cover containment: whether a problem stays small and gets caught. A "no" on either puts a landscape closer to A regardless of its size. The reasoning is set out in exposure vs. containment: the two kinds of integration risk. For a structured way to score all five factors from evidence, see the Integration Load Scorecard.
Count the Wiring, Not the Rooms
System count is worth tracking. It sets how much could go wrong, and in a peer-to-peer setup the number of connections grows faster than the number of systems. But it can't tell a fragile landscape from a stable one. That answer comes from whether ownership is defined, writes are validated, syncs are scoped to real changes, and failures are visible.
If you're trying to find out whether your landscape looks more like A or B, or how to move it from one to the other without disrupting what's already running, that's the work InAir does. Schedule a Discovery Call with InAir to find out what your integrations are actually carrying.