What should an automation do when a record arrives incomplete?

What should an automation do when a record arrives incomplete?

Stop early, say why, and leave the record somewhere a human will find it. The worst option is the common one: let the run continue, write half the data, and produce a record that looks finished but is not. A loud stop beats a quiet success every time.

This is the single most common way the automations I inherit are broken. Not a bad trigger, not a rate limit, not an API change. Someone submitted a form without a company name, or a linked record was empty, and the workflow kept going as though nothing had happened.

The fix is not more error handling bolted on at the end. It is deciding, before you build, what an incomplete record means and where you are going to catch it. That decision takes ten minutes and saves you a support conversation six months later.

Why do incomplete records break automations so often?

Because automations are written against the happy path. You build with a test record that has every field filled, it works, you ship it. Real submissions arrive with blank phone numbers, missing linked records and fields that were optional on the form but required downstream.

Airtable is explicit about this failure. Its own troubleshooting documentation describes the case where a record that triggered the automation is missing a required value for the action step to run. It also names a related one: when a recipient comes from a lookup or rollup through a linked record field and the triggering record's link is empty, the lookup returns nothing and the "To" input is empty. The same documentation attributes a "Failed to construct field values" error to missing information in a field that the automation needs.

Notice what those three have in common. In each case the record existed, the trigger fired correctly, and the automation did exactly what you told it to. The data was the problem. That is why adding retries does not help. A retry on a record with a blank field fails the same way, forever.

What is the difference between skipping, stopping and failing?

Skipping means this record is not for us and that is fine. Stopping means this record is for us but we cannot process it yet. Failing means something is wrong with the automation itself. These three need different handling, and collapsing them into one branch is where most workflows go wrong.

A skip should be silent. If you route enterprise leads to one owner and everyone else to another, the records that do not match are not errors and should not page anyone. A stop should be visible but calm: this lead is missing a company name, park it. A failure should be noisy, because it means your logic is wrong and every record after this one is at risk.

Most teams build only the third category and then wonder why their alerting is useless. If every non-happy-path outcome lands in the same error channel, the channel gets ignored within a fortnight. Then a real failure arrives and nobody looks. Separating the three is the cheapest reliability work available to you, and it pairs directly with deciding what to log when an automation runs.

How does a filter actually behave when a field is empty?

In Zapier, a filter is a gate on the whole run. Its documentation states that the Zap will only continue if the data from your app meets that condition, and that when a filter stops an item, the filter stops the Zap and no further actions are performed. That is a stop, not a skip of one step.

This matters when you want to skip a single action and carry on. A filter will not do that, because it halts everything after it. If you need one optional step to be conditional while the rest of the run proceeds, you need branching logic rather than a filter, and you should read the current vendor documentation for what your plan supports before you design around it.

There is a subtler trap in how filter rules are typed. Zapier's documentation notes that rules only work for the type of data specified in parentheses, giving the example that rules beginning with "(Text)" only work with text fields. So a text rule pointed at a number or a date field may not behave the way you assumed when you wrote it, and an empty value is exactly the input that exposes the mismatch. On conditions, the same page is clear: use AND when all conditions must be true for the Zap to continue, and OR when any one condition can be true.

Where should you validate, at the trigger or in the middle?

At the boundary, as early as you possibly can. The first step after the trigger should decide whether this record is complete enough to process. Validating in the middle means some writes have already happened, and now you are in the worst position in automation: a partial commit.

Partial commits are genuinely hard to clean up. Suppose your workflow creates a contact in HubSpot, then creates a deal, then posts to Slack. If it dies between step two and three, you have a contact and a deal and no notification, and a rerun will create a second contact and a second deal. You cannot undo the first two steps with a filter placed after them.

So my rule is that everything the run will need gets checked in one place before anything is written. Not field by field as each step needs it. One gate, one decision, one clear reason recorded. This is the same instinct as being deliberate about which CRM fields an automation is allowed to write at all, and for the same reason: reversibility is worth designing for before you need it.

What should happen to the record you refused to process?

It goes in a queue with a reason attached, not into a log file and not into the void. A rejected record is still a lead, a case or a customer. Discarding it to keep your dashboard clean is a business decision disguised as a technical one, and it is usually the wrong one.

The pattern I use is a quarantine view. The automation writes a status and a human-readable reason onto the record itself, then stops. Someone scanning that view can see "missing company name" and fix it in five seconds. The record re-enters the workflow when the field is filled, because the trigger is watching for completeness rather than for creation.

For Ajust I run automations on Airtable with WhaleSync that have delivered 25,000+ cases and helped 400,000+ people, saving 50,000+ hours. At that volume you cannot inspect runs individually, and nothing gets discarded silently. Anything the workflow will not process has to surface somewhere a person already looks. For Kismet Health the same principle applies on HubSpot through Zapier: the queue is part of the design, not an afterthought.

Why does a fixed automation sometimes keep failing?

Because you are testing the fix the wrong way. Airtable's documentation is direct about this: a rerun executes the automation's configuration as it stood when that run was first attempted, not your current configuration, so a corrected automation keeps failing on rerun and looks unfixed.

I have watched people lose an hour to this. They find the missing field, correct the automation, click rerun on the failed run, watch it fail again, and conclude the fix did not work. Then they change something else that was fine, and now there are two problems. The documentation's own guidance is to trigger a new run for that record to confirm the fix rather than rerunning the original.

The general lesson travels beyond one tool. Run history shows you what happened under the configuration in force at the time, which is what makes it useful for diagnosis and misleading for verification. Diagnose in the history, verify with a fresh run. If you spend much time in run history debugging a broken Zap, that distinction will save you repeatedly.

How do you decide which fields are truly required?

Work backwards from the first irreversible action. A field is required if the automation cannot take that action without it. Everything else is nice to have, and treating nice-to-have fields as mandatory is how you end up rejecting perfectly good leads because someone left off a job title.

Write the list down, in plain language, next to the automation. Something like: needs an email address because we create a contact, needs a company name because we route by company size, does not need a phone number because nothing downstream reads it. That document is the specification for your validation gate, and it is the thing you hand over when someone else takes the automation on.

Be honest about the routing fields too. If your logic branches on a field, that field is required whether or not the form marks it so, and you have to decide what a blank means. Defaulting a blank company size to "small" is a real decision with real consequences for whoever owns small accounts. I would rather park the record than guess, which is also how I think about who should get a lead the moment it arrives.

What should you do next?

Open your most important automation and find the first step that writes data somewhere. Then ask what happens if the record reaching it is missing one field. If the answer is that it writes anyway, you have found your next hour of work, and it is the highest-value hour available to you this week.

Then add the three things this article argues for, in order: one validation gate before the first write, a distinction between skip and stop and fail, and a quarantine view a human actually reads. None of it is clever. All of it is the difference between an automation you trust and one you check manually every Monday, which is not an automation at all.

I build these for clients on fixed fees, and the validation gate is the part I never cut from scope, because it is the part that decides whether the thing survives its first bad week. If you have an automation that keeps producing records nobody trusts, reach out and let's have a look at where it writes before it checks.