The Integration Handoff Package for Enterprise Airtable

A few weeks after the builder who set up a company's Airtable landscape, and who was also its workspace Owner, moved to another team, their account was deactivated as part of routine offboarding.

The signs were there, though not all in one place: the synced customer table showed a warning that it couldn’t sync from its source, the automations with Slack steps authenticated through that person’s account started failing because the app was no longer connected, and the CRM records that used to arrive through their personal access token stopped appearing, with the rejected requests visible only in the CRM’s own logs.

But the ops team worked only in interfaces, where the customer table still showed every customer it already held and the dashboards built on it still showed numbers. Hence, it took a sales manager asking why a new customer was missing before anyone noticed the sync had stopped updating on the day the account went.

Nobody on the team knew the sync was created under that person's account because nothing written down said so. That's the job of an integration handoff package: the documentation a team receives when someone hands over an Airtable system connected to other tools, whether that someone is an outside partner finishing a project or an internal builder moving to another role.

InAir has written about why internal builders become the bottleneck at scale. The handoff package is how what that person knows becomes something the team can work from. It isn't a tour of every table and field. It answers the questions a team will face the first time something changes or fails, and points to where the detail lives. This post covers its six sections and ends with a test that shows whether the package is complete.

1. What's Connected

The first section lists every connection into and out of the base: base-to-base syncs, syncs from external sources, integrations that write through the API, webhooks, automations that send to other systems, and tools someone connected by signing in with Airtable. For each one, it records what it reads, what it writes, and who owns it.

"Runs as" is the column that's easiest to leave blank, and section 6 depends on it.

Most of this list can come from the system boundary map drawn before the build, checked against what was actually built. If no record was ever kept, InAir's post on unmapped architecture covers how to reconstruct one from tokens, webhooks, syncs, and middleware, since Airtable's Metadata API describes a base's schema but not the bases that sync from it or the tools that read it through the API. A list written at handoff goes out of date with the next connection someone adds, so the package should hand it over as a living record rather than a document. Keeping it current after handoff is the subject of the integration registry.

2. Which System Has the Final Say

For every field that more than one system touches, the package names the system whose value is correct. That decision was made field by field in the boundary map, and the package carries it over with one addition the receiving team needs.

The rule for fields that still have two writers comes over from the map as it is, so nobody has to rediscover why one value overwrites the other. The addition is the last column. A rule enforced by a field permission or by how an integration is configured keeps holding after the builder leaves, while a rule enforced by agreement holds only as long as everyone remembers it, so the receiving team should know which of their rules are which.

3. Where the Business Rules Live

A business rule is a value or condition the system acts on: the discount above which a deal needs review, the status that sends an order to finance, the number of days before a record is archived. The package lists each one and the single place it's set, so a change is made there and nowhere else.

Rules that live in a settings table, read by formulas through a linked record and by integrations through the API, are the easiest to hand over, and centralizing business rules in Airtable covers how to set one up. Rules that live in a view filter need a warning in the package. An automation triggered when a record enters a view depends on that view's filter, so someone tidying up the view changes what the automation does without opening it. Where a rule still has copies in other tools, such as the same threshold typed into a Zapier filter, the package lists every copy until they're gone.

4. What Happens When an Update Fails

This section answers four questions for each connection: where failures are recorded, which failures retry on their own, who is told, and what that person does next.

Where failures are recorded. An automation’s run history shows failed and successful runs, and a failed run can be rerun from there, but the rerun uses the same inputs and configuration as the original run, so this feature doesn't always solve the problem, not to mention the risks of re-running an automation on outdated data. A safer option is to trigger the automation again by recreating its trigger conditions

Which failures retry on their own. A 429 rate-limit response should be retried after a 30-second wait, and a brief outage on Airtable's side retried with backoff, while a payload Airtable rejects as invalid won't succeed many times; however, it's resent. The package records what each integration actually does with each kind of failure, using the classification in retry logic for Airtable integrations. If an integration retries everything, or nothing, the package says so.

Who is told. Airtable sends failure emails for each automation to that automation's subscriber list. According to Airtable's documentation on managing automations, "Up to 10 subscribers can be added per automation," and "Only users or service accounts with workspace owner or base creator access can be added to the subscriber list." Whoever turns an automation on after creating it, or deploys a change to it by clicking Update, is subscribed automatically.

That makes the departing builder likely to be on every list for every automation they built, and possibly the only name on many of them. Once they’re gone, an automation with no subscribers left sends its failure emails to all workspace Owners, who may not know what it does or who should act on it.

The package records who is on each list today and who should be after handoff, and the receiving team updates the lists before the builder's last day. An automation must also be on to send failure emails, so one switched off during the handoff alerts no one. A person without workspace owner or base creator access can't be subscribed directly.

Otherwise, the alert has to be built, for example, as a script step that notifies them directly, and the package says which automations have one. A script that catches its own error without throwing it again stops the run from showing as failed in run history, so it should also write the failure to a log the team checks.

What they do next. A short runbook per connection, written for the person who receives the alert. For an API integration, it might cover three cases:

• A 401 or 403 means the token can't reach what it asked for: the account or token has lost access, or a table the integration writes to was removed or, if it's addressed by name, renamed. Check section 6 and recent schema changes before anything else.
• A 422 on every request usually means a field the integration writes was deleted, retyped, renamed (if the integration writes by field name), or had a select option renamed, so check recent schema changes. An integration that sends with typecast on may not fail on a renamed option at all, because typecast can add the old name back as a new option.
• A record that fails on its own goes to the dead letter queue for review. Since one invalid record fails a whole request of up to 10, the integration resends a rejected batch one record at a time to find it.

Each runbook ends with who to escalate to, by role, if the first steps don't resolve it.

5. What to Check Before Changing Anything

The receiving team will change the system. The package gives them a short checklist to run first, the same for a field, an automation, or a connection.

1. What depends on it. The field manager's Dependencies view lists the fields, automations, interfaces, syncs, and views that use a field, one level deep. It misses scripts that query a table directly rather than receiving the field as an input variable, and it never shows outside tools reading the base through the API, so search script code and check the integration registry too. Airtable integration impact analysis covers the full trace, including changes that don't touch any field.
2. Which system has the final say. If the change touches a shared field, its owner from section 2 agrees to it first.
3. Who reads what it produces. Every report, dashboard, and export that will show something different has a named reader who hears before the change goes live.
4. Where to test it first. A sandbox copy of the base that integrations can be pointed at, with its own tokens and the other systems' test environments. How to set one up is in how to test an Airtable integration in a sandbox base, and the package should say whether one exists and where.
5. How to undo it. Turn the old automation off rather than deleting it, keep the old field until nothing reads it, and know which steps can't be reversed.
   
   

6. Whose Account Everything Runs On

This section is easy to leave out, because nothing fails until the account is gone. Airtable’s guide to transferring ownership before leaving a company lists what stops when an Owner’s account is deactivated: automations that reach external systems, synced tables the Owner created, and syncs from external sources the Owner set up, and it recommends building integrations on a service account instead. As the opening example shows, a stopped sync keeps the data it already had, so a team that works only in interfaces can miss the warning in the base until a record that should be there isn’t.

The package lists every connection whose “Runs as” column in section 1 names the Owner, along with what moves each one off the Owner’s account before they leave, because tokens, syncs, and sign-ins keep running on the account that set them up.

Service accounts are available on Enterprise Scale. On other plans, a dedicated integration user that belongs to no individual does the same job. Either way, move a connection before the builder's account is deactivated, not after, so each one can be tested on its new account while the person who built it can still answer questions.

Testing the Package Before the Handoff Is Signed Off

A package is complete when someone who didn't build the system can work from it alone. To find out, give the receiving team three realistic situations and ask them to resolve each one using only the package, with the builder in the room but not answering.

Each question the team can't answer, or answers by asking the builder, is a gap in the package. Write the answer in, then run the situation again. Run the test while the builder is still around to fill those gaps, which for an internal builder means before their last day on the system, and for an outside partner means before the project closes.

The more systems a base connects to, the more this package has to carry. InAir's guide to running Airtable inside complex, high-volume system landscapes calls this Integration Load and shows how to assess it.

If your Airtable system depends on one person's knowledge, or you're about to take one over, Schedule a Discovery Call with InAir.