Why automations break: one renamed API field and 72 hours of silence

Automation Engineering · By Caleb Sakala · May 25, 2026

Here is a story about why automations break that has nothing to do with bad logic, wrong credentials, or server outages.

A mid-size SaaS company ran four Zapier workflows off the same HubSpot webhook. Lead routing, deal stage notifications, assignment emails, Slack alerts. Everything worked for eleven months. Then HubSpot shipped a minor API update that renamed deal_stage to dealstage, dropping the underscore from a single property.

The webhook kept firing. The workflows kept running. Every run showed a green checkmark in the Zapier dashboard. For 72 hours, all four workflows extracted a null value from the payload, routed every lead to the default fallback bucket, and sent zero notifications. Three days of new leads piled into one rep's queue while the rest of the sales team saw nothing.

Nobody caught it until a rep asked why their pipeline was empty.

Why automations break without throwing a single error

Most automation platforms track whether a workflow executed without errors. If the HTTP request returned 200, the step succeeded. If the data got written somewhere, the task completed. By that definition, all four workflows performed flawlessly for the entire 72-hour window.

The problem is that a workflow extracting a null value from a renamed field does not throw an error. It returns empty. The conditional logic downstream evaluates empty as "no match," which triggers the default branch. The automation did exactly what it was told. It just did something useless because the input silently changed shape.

This is the gap that kills automation reliability. Failed runs get caught by error alerts. Wrong runs get caught by humans, sometimes days later, sometimes never. According to Postman's 2025 State of the API report, 55% of API teams struggle with inconsistent documentation across their endpoints. Field renames and deprecated properties ship without advance notice to downstream consumers all the time.

Three days, one Slack message, and the debugging trail

The discovery came from a Slack message: "Is the lead routing broken? I haven't gotten anything since Tuesday." Someone checked the Zapier logs. All green. Someone checked HubSpot. Leads were flowing in normally. The disconnect between "leads are arriving" and "reps aren't getting them" took another two hours to trace.

The debugging path went like this. First, someone pulled a raw webhook payload and compared it to the field mapping in the Zapier step. The mapped field referenced deal_stage. The payload contained dealstage. Zapier's field mapper does not warn when a referenced field is absent from the incoming data. It returns null and moves on.

From there, the team had to figure out when the change happened, which meant scrolling through HubSpot's API changelog. The rename had shipped in a batch update three days earlier. No email notification went out for that specific change. The team then had to update the field reference in all four workflows, reprocess three days of leads manually, and explain to sales leadership why the pipeline data for that week was unreliable.

Total cost estimate from the ops lead: roughly 40 hours of combined team time across sales, ops, and engineering. That does not count the leads that went cold during the gap.

Schema validation at the boundary

Schema validation on the incoming webhook payload, before any business logic runs, would have cut that outage from 72 hours to under five minutes. Instead of immediately routing on the field value, the first step in the workflow should verify that expected fields exist and are non-null.

In practice, this means adding a filter or code step that checks: does the payload contain dealstage (or whatever the current field name is)? Is the value one of the expected options? If either check fails, the workflow halts and sends an alert to the ops channel instead of silently processing garbage data.

This sounds obvious, and it is. But almost no one does it. Automation platforms optimize for the setup experience, for getting a workflow running in five minutes. Adding validation steps slows down the initial build and adds nodes that "don't do anything" from a business logic perspective. The incentive structure pushes toward fragile-fast rather than resilient-slow.

That 72-hour gap, the 40 hours of team time, the cold leads that never came back: all of it traces to a workflow that trusted its inputs instead of checking them. On Chase Agents, input schema validation runs before execution begins, so when a required field is missing or shifts type, the run gets flagged instead of processed. That is the difference between a three-minute Slack alert and a three-day outage discovered by accident.

Every hardcoded field reference is a bet

Zoom out. Every time a workflow maps response.properties.deal_stage to an internal variable, that mapping is a bet. That bet assumes the upstream provider will never rename, restructure, deprecate, or remove that field. For one field in one workflow, the odds are decent. But a typical production automation has ten to thirty field references across five to eight connected services. The probability that none of those fields change over twelve months drops fast.

The competing articles about this topic recommend abstraction layers: instead of referencing API fields directly in your workflow logic, route all data through a normalization step that translates raw API responses into your internal schema. When the upstream changes, you update one translation layer instead of every workflow.

That advice is correct. It is also advice that almost nobody follows because automation platforms do not make it easy. Zapier, Make, and n8n all use direct field mapping as their primary interface pattern. You click a field from the trigger output, it gets inserted into the action input. That directness sells the product. It also creates the fragility.

A contrarian position on this: the abstraction layer approach works for engineering teams that build automations in code. For operations teams using visual workflow builders, the overhead of maintaining a separate translation layer often exceeds the cost of occasionally fixing broken field mappings. The better investment for most teams is aggressive payload validation at workflow entry points (catch breakage in minutes) rather than abstraction layers (prevent breakage but triple the maintenance surface area). Disagree? That probably depends on how many workflows you run and how much engineering support you have access to.

Why automations break worse on the second failure

The 72-hour scenario above involved one renamed field. Consider what happens when the problem compounds. A workflow that processes customer support tickets extracts the priority field to determine routing. The upstream helpdesk provider changes priority from a string ("high", "medium", "low") to an integer (1, 2, 3) in a version bump. The workflow still runs. But the conditional logic that checks for priority == "high" never matches. Every ticket routes to the general queue. High-priority tickets from enterprise customers sit for hours instead of minutes.

That second scenario played out at a company using a Chase Agents automation to route support tickets across three Slack channels. Because the platform validated the input schema at the workflow boundary, the run flagged when the priority field type shifted from string to integer. The ops team got a Slack alert within four minutes. They updated the schema mapping and reprocessed the two tickets that had arrived during the gap. Total disruption: under fifteen minutes.

The difference between these outcomes has nothing to do with the complexity of the workflow or the skill of the team. It comes down to one architectural decision made at build time: does the workflow validate its inputs, or does it trust them?

Count your bets

Open your most critical automation. Count the number of fields it reads from external APIs. That count is the number of silent-failure bets you currently hold. Each one pays off fine for months or years, right up until it does not.

The question is not whether one of those fields will change. It is whether your workflow will tell you when it happens, or whether you will find out the same way that sales team did: three days late, from a confused Slack message.