FixScenarioTwelve errors, and the real cause behind each
The mapping is there, but it resolved to nothing. Almost always the module upstream produced no such property — either it returned an empty bundle, or its output structure changed and Make is still mapping the old shape.
Where to look: Run the upstream module once on real data so Make relearns its output, then re-pick the field instead of typing it.
A value arrived in the right place but the wrong form: text where a number is expected, a date string the app will not parse, or a single item where the field wants a collection.
Where to look: Look at the resolved value in the execution log, not at the mapping. The mapping is usually fine; it is the shape that is wrong.
You hit the app's rate limit. The trap is that the limit belongs to the connection, not the scenario — another scenario sharing that connection can be the one spending the quota.
Where to look: Check which other scenarios use the same connection before adding a sleep. Then add an error handler with a break and a retry rather than letting the run die.
Either the token expired, or the connection was authorised for a narrower scope than the operation needs. A connection that works for reading can fail on writing for that second reason.
Where to look: Reconnect and re-check the scopes granted. If it worked yesterday and fails today with no change, it is the token.
The scenario is listening on a URL nobody is calling any more. Re-creating a webhook gives it a new URL, and the source system keeps posting to the old one.
Where to look: Compare the URL in the Make webhook with the one registered in the source app, character for character.
Either the array really is empty, or the module never learned its structure, so Make sees a text blob where you expect a list.
Where to look: Run the source module once, click 'Redetermine data structure', then map the iterator's output again.
The aggregator is pointed at the wrong source module, so it groups over a different loop than the one you meant.
Where to look: Check the 'Source module' dropdown first — this is a configuration mistake far more often than a data one.
The condition compares values that look identical on screen but are not: a number stored as text, a trailing space, a different date format, or a null the operator does not match.
Where to look: Use the execution log to see the raw value on both sides of the operator, then pick the matching operator type (text vs numeric).
A loop is running far more times than intended, usually because a search returns everything instead of a filtered subset.
Where to look: Look at the bundle count on each module in the execution. The one that jumps is the culprit.
The other service was down or overloaded. Nothing in your scenario is wrong.
Where to look: Add an error handler with a retry and a delay so a transient outage does not stop the run.
The source retried a webhook delivery that it considered failed, and the scenario has nothing to recognise a duplicate.
Where to look: Return a 200 quickly, and key your writes on an id from the payload so a repeat is harmless.
The write landed somewhere you are not looking: the wrong sheet, the wrong base, the wrong folder — the connection has access to several and the module points at another one.
Where to look: Open the record the execution log links to, rather than the one you expected.
Not on the list?
Paste the error into FixScenario with your blueprint. It combines recognized error patterns with the supplied workflow context. An unfamiliar error may require more evidence or remain inconclusive.
Something broke right now?
Paste the error. Your first 3 completed analyses are free.
Diagnose my workflow