How Do You Test a Make Scenario With Fake Leads?

How do you test a Make scenario without touching real leads?

Test a Make scenario without touching real leads by sending clearly labeled fake leads through it while every outbound action is pointed at a sandbox or filtered out. Build a small set of test records that cover normal, messy, and broken inputs, run each one, and check every destination before you switch the scenario on for real traffic.

Lead workflows are the automations I see break most painfully. They touch your CRM, your sales team's notifications, your email tools, and sometimes your ad platforms. A bad test with a real lead can send a welcome email to a prospect, assign them to the wrong rep, or create a duplicate that lives in your CRM forever.

Fake leads remove most of that risk. This post walks through how I design them and how I run the test in Make.

Why not just test with a real form submission?

Testing with a real submission is risky because the scenario will do everything it was built to do. It will create CRM records, trigger email sequences, ping Slack, and maybe enrich the contact with paid credits. A single test can leave a trail of real side effects that someone then has to find and clean up by hand.

Real submissions also test only the happy path. Your own test entry probably has a perfect email, a full name, and a company domain. Real leads arrive with typos, missing fields, personal email addresses, and odd characters in names. Those are the inputs that break scenarios in production.

So the goal is not just safety. It is coverage. Fake leads let you test the weird cases on purpose, before a real buyer finds them for you.

What should a set of fake leads include?

A good set of fake leads includes one clean record, one with missing optional fields, one with a personal email domain, one with special characters in the name, one duplicate of an existing test contact, and one that should be rejected outright. Each fake lead should be obviously fake, so nobody mistakes it for a buyer.

Make every record easy to spot. Use a consistent marker, like a first name of "Test" and an email on a domain you control, with a plus tag such as test+missingfields@yourdomain.com. That way you can filter them out of reports and delete them in one sweep later.

Write down what you expect for each one before you run it. Which CRM fields should be filled? Which owner should be assigned? Should the record be created, updated, or skipped? A test without an expected result is just a demo.

The duplicate case matters most for lead workflows. If your scenario does not handle a contact that already exists, you will find out the first time a real buyer fills in a second form. I covered that failure in my post on changing a live automation without breaking it, and the same principle applies to testing.

How do you stop fake leads from triggering real side effects?

Stop side effects with a filter near the start of the scenario that routes test records away from irreversible actions. Check for your test marker, such as the email domain or a "Test" first name, and send those bundles down a path that logs results instead of emailing people, enrolling sequences, or spending enrichment credits.

In Make, a router with a filter on each route is a clean way to do this. One route handles real leads with the full set of actions. Another handles test leads and writes results to a log, like a Google Sheet or an Airtable table, so you can inspect what the scenario would have done.

For CRM writes, I prefer a sandbox when one is available. If your CRM offers a test environment, point a copy of the scenario at it. If not, let test records into the real CRM with the test marker, and make sure every downstream workflow in the CRM ignores records with that marker.

Turn off anything that costs money per run while you test, such as paid enrichment steps. Map placeholder values in their place, then switch them back on for the final test.

How do you run the test in Make?

Run the test by sending each fake lead through the trigger one at a time and running the scenario manually. After each run, open the execution details and check what every module received and returned. Then check each destination, such as the CRM record, the log sheet, and any notification, against what you expected for that lead.

Make shows the input and output of each module for a run, which is where most bugs reveal themselves. A field mapped to the wrong source, a date in the wrong format, or an empty value where you expected a fallback will all be visible there.

If your trigger is a webhook from a form, submit the fake leads through the real form on a staging page, not by pasting data into Make. That tests the whole chain, including how your form tool formats the data. If you build forms in Webflow, a hidden test page with the same form works well.

Fix one issue at a time and rerun the same fake lead. Do not move on until each record produces exactly the result you wrote down.

Can you replay runs instead of resubmitting fake leads?

Yes, with care. Make's scenario run replay runs the current version of a scenario using the trigger data from a previous run. That is useful for retesting after a fix. But Make notes that replay can send data to third-party systems and that replayed runs consume credits, so the same side-effect rules apply.

Make's help center says scenario run replay is available on all plans and that a run is replayable as long as it remains in the scenario history, which varies by plan. It also says bulk replay is not currently possible, so you replay runs one at a time.

I use replay after fixing a bug that a fake lead exposed. Run the fake lead once, find the bug, fix the scenario, then replay that run to confirm the fix. It saves resubmitting the form each time. For how errors route inside a scenario while you test, see my post on error routes in a Make scenario.

What do you check before going live?

Before going live, confirm every fake lead produced its expected result, every test record is marked and removable, error handling catches the broken input instead of stopping the scenario, and the test filter cannot accidentally catch real leads. Then run one final clean fake lead through the full real path with all actions switched on.

That last check is easy to skip and important. The test route proved your logic. The final run proves the real actions work, like the actual email template, the actual Slack channel, and the actual CRM workflow. Use your own address so the email lands with you.

Also check the filter itself. If your test marker is "first name equals Test," a real person named Test will get filtered out. A marker on an email domain you own is safer.

How do you clean up after testing?

Clean up by deleting or archiving every record that carries your test marker in the CRM, the log, and any other destination, then confirm reports exclude them. Keep the fake lead set and expected results in the scenario's documentation, so the next person who changes the scenario can rerun the same tests in minutes.

The saved test set is the real long-term value. Scenarios change. Someone adds a field, swaps an enrichment provider, or changes the routing rules. With a saved set of fake leads and expected results, every change gets the same test, and regressions show up before a real lead does.

I treat this as part of the build, not an extra. In my view, a lead automation is not finished until its test leads and a short note on how to run them exist.

What should you do next?

Pick your most important lead scenario in Make and write six fake leads for it: clean, missing fields, personal email, special characters, duplicate, and reject. Add a test filter that routes them away from irreversible actions, run each one, and compare results with what you expected. Save the set in the scenario's documentation.

Then make it a habit. Any change to the scenario gets the same six leads before it goes live.

If you want help building a test setup for your lead workflows in Make, Zapier, or n8n, reach out. I am happy to help you make them safer to change.