Make Scenario Not Working? How to Find and Fix the Cause

Why is my Make scenario not working? Start with the execution history

A scenario that looks correct on the canvas can still fail at run time. If your Make scenario is not working, the most useful evidence is the run history and the output bundles of each module.

Open the latest failed or incomplete run and look for the first module that shows an error. Later errors are often side effects of that one.

Read the error message and the input and output bundles of the failing module. Note whether the module received what you expected.

An empty field, a text value where a number is expected, or an array where a single item is expected explains many failures.

What causes a Make scenario to fail?

The order below is a practical guide, from most to least common. Confirm each cause against the error message rather than assuming.

Connection or permission problems: an authorisation may have expired, been revoked, or lack the required scope. Typical signs are authorisation or permission errors on modules for email, spreadsheets, or a CRM. Reauthorise the connection and check the app's own permission settings.

Bad field mapping: a mapped value may point to a module that did not output data in that run, often because a filter or router route skipped it. Values may also be empty for some records.

Data format issues: dates, phone numbers, list fields or line breaks that the target app rejects. Check the target app's documentation for accepted formats.

Rate limits and quotas: the app or Make itself may reject or delay requests when too many are sent at once. Check the app's API limits and your Make plan limits in the official documentation.

Scenario logic: iterators and aggregators used incorrectly can send a message once per row when it should be once per contact. Duplicates can also appear when nothing checks whether a record was already processed.

How do I fix a failing Make scenario step by step?

Work on one problem at a time and re-run after each change, so you know what fixed it.

1. Open the scenario history and select the first failed run. Identify the earliest module with an error.
2. Inspect that module's input bundle. Compare it with the output of the previous module to find empty or wrongly typed values.
3. Reauthorise or recreate the connection if the message mentions authorisation, tokens or permissions.
4. Remap fields using the values from the actual output, not typed-in text. Add fallback values where a field can be empty.
5. Add or correct filters so records with missing required data (for example no email address) stop before the sending step.
6. Run the scenario once on a single test record, sending to an address you control, and check the result in the destination app.
7. Add a duplicate check, such as a status column or a lookup, so a contact is never processed twice.
8. Turn on the schedule only after a small batch behaves correctly.

How do I add error handling before launch?

Make provides error handler routes for modules. Review the official documentation for the available directives and what each does to the run, since ignoring an error and stopping the run have different consequences.

For an outreach flow, a sensible approach is to log the failed record with its error message to a sheet or notification, then continue with the next record.

Also check the scenario settings for how incomplete runs are stored and retried. Set up a notification for failures so problems are noticed quickly.

For email outreach, confirm that sending limits, unsubscribe handling and consent requirements for your region are met. Check the relevant regulations and your email provider's policies.

Common mistakes and when to get help

Common mistakes include testing with real contacts, changing several modules at once, and ignoring the first error in a run. Others are mapping from a module that sometimes outputs nothing, and activating the schedule without a duplicate check.

If you hire an expert, give them a clear scope: fix a specific scenario rather than rebuilding it. Share a description of the flow, example error messages with personal data removed, and a test dataset.

Grant the minimum access needed, use a separate user or team role if the platform allows it, and rotate credentials afterward.

Professional help is worthwhile when the problem involves custom API calls, webhooks, or compliance questions you cannot resolve from the documentation.