Field notes
What a Make scenario looks like six months after the person who built it left
8 June 2026
On this page
A client came to me in April with a simple question: why is our CRM missing leads from the last quarter? We went looking. There was a Make scenario that had been pulling form submissions from Typeform, enriching them, and pushing records into HubSpot. It was built eighteen months ago by a contractor who left the following spring. The scenario had last executed successfully in October. Nobody had noticed because the sales team assumed the leads were just slow. They were not slow. They were gone.
This is not a story about Make failing. Make did exactly what it was told. The webhook URL it was listening to pointed at a Typeform form that had been archived when the team switched to Tally. No new submissions ever arrived. No error fired. The scenario sat there, healthy by every internal metric, waiting for data that would never come.
This is what automation debt looks like in practice. Not a crash. A silence.
When someone builds a Make scenario, they carry most of the context in their head. They know why the filter on step four exists. They know the Google Sheet in step seven is a staging buffer because the destination API rate-limits at 100 requests per minute. They know the scenario runs at 6am because the source system exports a nightly batch.
When they leave, none of that transfers automatically. What transfers is the scenario itself, which in Make is a visual graph of modules and connections. The graph tells you what the automation does mechanically. It tells you almost nothing about why it does it, what depends on it, or what breaks upstream and downstream when it stops.
The institutional knowledge walks out with the person. What remains is a running process with no owner and no memory.
This is drift, not failure. The scenario does not break on day one. It degrades slowly as the environment around it changes: tools get replaced, API versions deprecate, webhook endpoints go stale, the Slack workspace it posts to gets reorganised. Each change widens the gap between what the scenario was built to do and what the world now looks like. At some point the gap becomes a chasm and something stops working. By then, nobody remembers what it was supposed to do in the first place.
The stale webhook. A webhook URL is hardcoded into a source tool. The source tool gets replaced or the form gets archived. New submissions never reach the scenario. The scenario reports zero errors because from its perspective, nothing arrived. This was exactly the Typeform-to-Tally situation above. I have seen the same pattern with Calendly replaced by Cal.com, with Gravity Forms replaced by Tally, with a custom-built intake form replaced by a third-party portal.
The silent filter. Someone added a filter mid-scenario to handle an edge case. The edge case was temporary. The filter was never removed. Six months later, a new data pattern matches the filter condition and entire record sets start getting dropped silently. No error. Just missing data.
The orphaned Google Sheet. A scenario writes to a Google Sheet as an intermediate step. The Sheet was shared with the contractor's personal Google account. The contractor leaves. The account gets deactivated. The scenario now fails on every run with a permissions error. If there is no error alerting, nobody knows.
The deprecated API version. A Make HTTP module is calling a third-party API at v1. The provider deprecated v1 in March. The scenario now returns 410 responses. Make logs this as an error, but if nobody is watching the error log, it is functionally invisible.
None of these are exotic. All of them are common. The pattern across failed AI and automation pilots is almost always the same: the tooling worked, the process design did not survive contact with organisational change.
Most small ops teams treat error alerting as a nice-to-have. It is not. It is the difference between finding out about a broken scenario in an hour and finding out in a quarter.
Make has built-in error handling. You can add an error handler route to any module and route failures to a separate scenario that posts to Slack. Zapier has task history and email alerts. n8n has execution logs and can trigger a workflow on failure. These features exist. They are not used by default on most scenarios I audit.
The minimum viable observability setup for any scenario that touches live business data:
- An error handler that posts to a dedicated Slack channel (not a general ops channel, a specific one called something like
#automation-errors) - A weekly execution summary, even if it is just a count of successful runs posted to the same channel
- A last-run timestamp visible somewhere a human checks regularly
That last one sounds obvious. It is not done. I have audited scenarios where the only way to tell if they were running was to open Make, navigate to the scenario, and look at the execution history manually. Nobody was doing that. Nobody had a reason to, until something broke.
The Slack error channel approach is low-effort and high-signal. When the channel goes quiet for a week on a scenario that usually fires daily, that silence is itself an alert.
Comprehensive documentation does not get maintained. I have seen beautifully structured Notion pages describing automation workflows in detail. They are always six months out of date. The person who wrote them left.
What gets maintained is documentation that is embedded in the scenario itself and takes thirty seconds to update.
Here is the minimum I now require for any scenario I build or audit before handover:
scenario:
name: "Tally intake to HubSpot contact"
owner: "ops@example.com"
last_reviewed: "2026-06-08"
purpose: >
Receives new submissions from the main website contact form (Tally).
Creates or updates a HubSpot contact. Tags with source = website-intake.
Sends internal Slack notification to #new-leads.
dependencies:
source: "Tally form ID 9xkQz2 — website contact form"
destination: "HubSpot portal 12345678"
notifications: "Slack #new-leads webhook"
known_quirks:
- "Filter on step 4 excludes submissions where email domain = @test.com. Do not remove."
- "Runs on webhook trigger only. No schedule."
error_alerting: "Slack #automation-errors via error handler on module 7"
what_breaks_if_this_stops: >
New website leads do not reach HubSpot. Sales team will not follow up.
Check this if lead volume drops unexpectedly.This lives as a note inside the Make scenario description field, or in a pinned message in the #automation-errors Slack channel, or both. It is not comprehensive. It does not need to be. It answers the four questions that matter when something breaks: what does this do, what does it depend on, what is weird about it, and what breaks if it stops.
The "what breaks if this stops" field is the one most people skip. It is also the most important. It tells a future ops hire whether to treat a broken scenario as urgent or not.
If you are thinking about how this connects to broader data quality problems, the same principle applies to CRM records. Automation that feeds bad data into a CRM compounds the problem at scale, and the audit trail for how records got corrupted is usually just as absent as the scenario documentation.
Do this in order.
Week one: inventory. Open Make (or Zapier, or n8n). List every active scenario. Note the last successful execution date. Flag anything that has not run in thirty days. Flag anything with no error handling configured.
Week two: triage. For each active scenario, answer: what does this touch, and what breaks if it stops? You may need to ask around. That process of asking around is itself useful. If nobody knows what a scenario does, that is a risk.
Week three: add error alerting. For every scenario that touches live business data, add a Slack error handler. This takes ten minutes per scenario in Make. Do it before anything else.
Week four: document the three highest-risk scenarios. Use the YAML structure above or any format that answers the four questions. Do not try to document everything at once. You will not finish and you will stop.
After that, make documentation and error alerting a condition of any new scenario going live. Not a recommendation. A condition.
Automation debt is not a technology problem that better tooling solves. It is an institutional memory problem that process design prevents. The scenario that broke in October was not badly built. It was built without any mechanism for surviving the departure of the person who understood it.
If you have inherited a set of scenarios you did not build, or you are about to hand off workflows to a team that did not build them, an AI Workflow Audit is the fastest way to map what you actually have, identify what is silently failing, and put the observability layer in place before the next builder leaves.