When a scenario stops with a bundle validation error, one module refused the data another module handed it. The run halts at that module and the message names both the module and the field that failed. The cause is almost always one of four things: a required value is empty, the data arrived in the wrong type, a mapping points at a field that was renamed or deleted, or a module was handed a whole collection where it expected a single value. Each one is fixed in the module that threw the error, not by rebuilding the scenario. Attach an error handler and the rest of the run keeps going while you correct the field, so one bad packet no longer takes the whole automation offline. Nothing here needs code, a new connection, or a fresh scenario.
What does a bundle validation error actually mean?
A bundle is the packet of data one module sends to the next. Every time a module finishes, it passes its output forward as a bundle, and the next module reads the fields it needs from that packet. Validation runs at that handover. When the receiving module cannot accept what it was given, Make stops the packet there and marks the run as an error, and the history shows the failing module in red.
The message is specific on purpose. It names the module, the parameter group, and the field that failed, then gives the reason. A blank value, a type that does not match, and a mapping that resolves to nothing are the usual entries. Because the check sits between modules, the module that carries the error is the one that rejected the data, not always the one that produced it. The bad value can be born earlier in the flow, which is why the fix sometimes belongs to a different module than the one flagged. A related trap appears when a source writes into a database that expects typed fields, which is where Notion property types cause the same class of rejection.
What causes a bundle validation error?
Four causes cover the vast majority of these errors, and each leaves a different fingerprint in the message. Read the error text first, then match it against the table before you touch anything.
| Cause | What The Error Shows | How To Fix It |
|---|---|---|
| An empty required field | A parameter the module needs arrived with no value | Map the value or set a fallback in the module |
| A data type mismatch | A number, date, or select field received text | Format the value or repair the source column |
| A mapping to a moved field | A mapped field shows as unmapped or null | Reload the field list and re-select the field |
| A collection in a single slot | The message names a bundle, array, or collection | Add an Iterator or map one item from it |
The pattern is worth noticing. Three of the four come down to a gap between what a source produced and what a destination demanded, and only one is a fault inside Make itself. That is why the fastest fix is usually to compare the source module’s output against the receiving module’s field settings, rather than to edit the scenario’s logic.
How do you clear each cause?
The empty required field. Open the module that threw the error and read the field it names. A required field arriving blank is the most common entry, and it usually traces back to a source with nothing to send: a skipped form question, an empty spreadsheet cell, or a property the previous module never filled. Map the value from the correct source, or set a default so the run survives a blank.
The type mismatch. Make records a value with a type, and a field that wants a number rejects text. A date arriving as a plain string, a number stored as text because the column was formatted that way, or a select option that no longer matches the list all land here. Send the value through the matching format function, or fix the type where the data originates.
The mapping that moved. When a source field is renamed or deleted, the mapping keeps pointing at the old name and resolves to nothing. Reload the field list in the module, then re-select the field from the refreshed panel. When the failure starts at the trigger instead, the debugging order in our webhook failure guide covers that side of the chain step by step.
The collection in a single-value slot. Some fields accept exactly one value, so an array or a whole bundle fails the check. Add an Iterator to split the collection into single bundles, or map one specific item from it.
Which error handler should you attach?
An error handler decides what happens after a module fails, so a single bad packet no longer stops a scheduled scenario. Right-click the module and choose a directive. The four main choices do different jobs.
| Directive | What It Does | When To Use It |
|---|---|---|
| Resume | Supplies substitute output and continues the run | A value can be swapped for a default |
| Break | Stops the flow and stores it as an incomplete execution | The data can be repaired and replayed later |
| Ignore | Continues the scenario with no output from the module | The failed bundle can be skipped without harm |
| Rollback | Restarts the scenario from the beginning | The whole run must start clean |
Resume is the directive most teams reach for, because it turns a hard stop into a soft one and keeps the schedule on track. Break is safer when the incomplete data still matters, since Make holds the failed run in the Incomplete executions folder until you resolve it. Attach the handler to the module most likely to receive bad data, not to the trigger, and the run keeps moving while you fix the field underneath. The wider build, from trigger to schedule, is walked through in our Make.com tutorial.
How do you stop the error from coming back?
Fix the cause, then close the gap that let it through.
- Read the message and note the module and the field it names.
- Decide whether the field is empty, the wrong type, or unmapped.
- Repair the value or the mapping in the module that rejected the data.
- If the source produced the bad value, repair it earlier in the flow.
- Attach an error handler so the next bad packet does not stop the run.
- Check Incomplete executions for anything a Break handler parked.
Two habits prevent repeats. Validate at the source, so a required field is never left blank upstream, and add a filter before a picky module to drop incomplete bundles before they reach the check. Neither habit repairs data, but together they keep a scheduled scenario running through the messy days.
FAQ
What does a bundle validation error mean in Make.com?
A bundle is the packet of data one module sends to the next. The error means the receiving module could not accept that packet, so the run stops at that module and the history marks it as an error. The message names the module and the field that failed.
Why does the error point at a module I did not change?
The check runs at the handover between modules, so the module showing the error is the one that rejected the data, not always the one that produced it. A source field that was renamed, emptied, or retyped earlier in the flow is a common cause.
Does an error handler fix a bundle validation error?
No. An error handler decides what happens after a module fails and cannot make invalid data valid. Use it to keep the rest of the run alive, then fix the field, type, or mapping behind the failure.
Can a filter prevent a bundle validation error?
Sometimes. If a bundle is missing a value the next module requires, a filter placed before that module drops the incomplete bundle before it reaches the check. The filter keeps bad packets out, it does not repair them.