For an operations manager who inherited automations: find out what runs, who owns it and who is told

Start with an inventory, not a rebuild

An automation you did not build is a black box that something depends on. Before changing any of them, list them. For each, record the tool and its name, what starts it, which apps it reads and writes, when it last ran, who owns it and who is told when it fails. Most of this is visible in each platform's own list and run history. Anything you cannot fill in is itself a finding: an automation with no owner and no alert is the first one to look at.

• Name, platform and the account it lives in.
• Trigger and the apps it touches.
• Last run date, and how often it normally runs.
• Owner, and who is told on failure.
• What breaks for the business if it stops.

Look for overlaps and loops

Two automations that start from the same event will both fire, because Zapier's de-duplication checks only within one Zap. An automation that writes back to the record type it watches can trigger itself. Two tools doing the same job, for example a Zap and an Airtable automation both emailing on a status change, double every message. These are the first targets for consolidation. Note them without deleting anything yet.

Check what happens when each one fails

Failure alerts follow settings someone chose once. Airtable sends the failure email to the last person who turned the automation on, or to the workspace owners if that person has left. Make deactivates a scenario after repeated consecutive errors, three by default, and a webhook-triggered one at once. For each automation that matters, find out who would be told and test it with a deliberate failure on a copy. If the answer is one person's inbox, fix that first.

Decide keep, merge or retire, and switch off rather than delete

For each overlap, someone with authority decides: keep one, merge two into one, or retire one. Retire by switching off, not deleting, and keep it for an agreed observation period so a dependency nobody remembered can show itself and the automation can come back. Switching it back on does not catch up on what happened while it was off: Zapier says a Zap does not fire for data created before it was turned on. Note when you switch each one off and what to compare in the source app afterwards. Note that in Airtable a switched-off automation still occupies a slot against the base's cap, and only deleting it frees the slot, so deleting is a decision to make after the observation period, not before.

• Write each decision and who made it.
• Switch off, note the time, wait, then delete.
• Give every remaining automation an owner and an alert.

Which paid job fits

If one automation duplicates records, halts on a bad record or fails in Airtable, the matching one-off outcome repairs it on a copy and proves the fix with synthetic data. If nobody is told when automations fail, the alerts outcome covers up to five. If you want someone watching named automations week by week, the standing service reviews run history and prepares corrected copies, with no response-time promise. If the whole set is a tangle, the project inventories it, settles each overlap with you and returns a smaller set with an owner, an alert and a runbook. You switch every change on.