How to Pass Context Between Steps in a Make Scenario

Why does your Make scenario lose track of the lead halfway through?

Usually because context lives in too many places. The lead's ID sits in module 1, the owner in module 4, and the score in module 7. Once you add a router or a loop, later steps cannot find what they need. The fix is to decide early where each piece of context lives and pass it on deliberately.

Picture a typical lead workflow in Make. A form comes in, the lead gets enriched, scored, routed to an owner, and logged. On paper that is five steps. In a real scenario it is often twenty modules, with routers, filters, and error handlers in between.

The scenarios that break in production are rarely the ones with hard logic. They are the ones where nobody planned how data moves from step to step. This guide covers the patterns I use so a scenario still knows who the lead is on module twenty.

What does "context" mean inside a Make scenario?

Context is every piece of information a later step needs to do its job. For a lead workflow, that is usually the record ID, the email, the source, the owner, the score, and a run ID for logging. If any step has to guess or look these up again, your context is leaking.

Make moves data through mapping. In Make's own words, "Mapping is how Make knows what information to get from one app and which app to send it to." Each module returns its output in bundles, which the help center describes as "like a box of information." Later modules can map any field from those bundles.

That model works well for short, straight scenarios. The trouble starts when the path splits or repeats. Then the question becomes which bundle a field came from, and whether that bundle is still the one you think it is.

When is direct mapping from earlier modules enough?

Direct mapping is enough when the scenario runs in a straight line and each value is used once or twice. If module 6 needs the email from module 1, map it straight from module 1. Adding a variable for a value you use once only adds a step to maintain.

The rule I follow is simple. Map from the original source whenever you can. If the email came from the form trigger, map it from the trigger, not from a later module that happened to echo it back. The original source is the one least likely to be transformed by mistake.

Direct mapping starts to hurt in two cases. One is when a value is transformed, such as a cleaned company name or a computed score, and several later modules need the cleaned version. The other is when routers split the path and each branch needs the same values. Both cases point to variables.

When should you use Set variable instead?

Use Set variable when you compute a value once and reuse it in several later steps. Make's help center says you can use the Set variable and Set multiple variables tools to define scenario variables, and that variables "can be mapped to any module" input field. That gives you one clean value to reference.

My favorite use is a context block near the start of the scenario. Right after the trigger and any cleanup, I add one Set multiple variables step. It holds the normalized email, the lowercase domain, the lead source, and a run ID. Every later module maps from that block, not from scattered earlier steps.

The benefit shows up during debugging. When something goes wrong, you open one module and see exactly what the scenario believed about the lead. You do not have to trace five modules back to find where a value changed. It also makes the scenario easier to hand to someone else.

How long does a scenario variable last?

Only as long as the scenario is running. Make's documentation says scenario variables "only exist in the current scenario" and "no longer exist when the scenario stops running." So a variable is perfect for passing context within one run, and useless for remembering anything between runs.

That limit catches people. Someone sets a variable called last_processed_id and expects the next run to read it. The next run starts clean, and the value is gone. If you need memory between runs, you need a different tool.

Make does offer incremental variables, which its help center says can keep their value across multiple scenario executions. They suit counters, like numbering runs. For anything richer, such as remembering which leads were already processed, use a data store or your CRM.

When do you need a data store or the CRM instead?

Use a data store or the CRM when context must survive between runs or be shared across scenarios. Make describes data stores as a way to "store and manage data across scenarios." That makes them right for things like a processed-leads list, a lookup table, or state that two scenarios both read.

My preference is to keep business state in the CRM and technical state in a data store. The lead owner, lifecycle stage, and score belong in HubSpot or whatever CRM you use, because sales needs to see them. A record of which webhook IDs already ran belongs in a data store, because only the automation cares.

That split also helps with duplicates. If the same form submission arrives twice, the scenario can check the data store for the submission ID and stop early. I wrote more about that pattern in how to make an automation safe to run twice.

How do routers and filters change the way you pass context?

Routers split one path into several, and each branch only sees what came before the split. So set your context block before the first router. Then every branch maps from the same values, and you never have to rebuild them inside a branch or wonder which version a branch used.

Filters are quieter but just as important. A filter can stop a bundle, which means later modules in that path never run. If a later step logs results, a filtered bundle leaves no trace. I like to log the filter decision itself, so I can see why a lead stopped.

Loops need the most care. When you iterate over a list, such as several contacts from one company, each pass works on one item. Before you build on fields from before the loop, test which ones are still available to map after it. Make's help center documents how iterators and aggregators behave, and it is worth reading before you rely on them.

What naming habits keep context readable?

Name variables for what they mean, not where they came from. A variable called lead_email_clean tells the next person exactly what it holds. A variable called email2 tells them nothing. Good names make a scenario readable without opening every module, which matters most at 2 a.m. during an outage.

I also give every module a plain label. A label like "Score lead" beats the default app name. When a scenario has three HubSpot modules, labels are the only way to tell them apart at a glance.

Finally, add a note at the top of the scenario that lists the context block fields and what each one means. It takes five minutes and saves the next person an hour. If you test scenarios with fake data, include the context block in every test case, as I covered in how to test a Make scenario with fake leads.

How should errors carry context?

Every error path should carry the run ID and the lead ID at minimum. When an error handler fires, the alert should say which lead failed, at which step, and why. An alert that says "scenario failed" without context sends you hunting through the run history to find the lead yourself.

This is where the context block pays off again. Because the run ID and lead ID live in one place, every error route can map them into the alert message. I usually send that alert to a Slack channel the client's team already watches.

It also helps to tell the alert what to do next. A short line like "lead was not routed, assign manually" turns an error into a task. I go deeper on this in how to design error routes in a Make scenario.

What should you do next?

Open your busiest Make scenario and list every value that more than two modules use. If those values are mapped from scattered places, add one Set multiple variables step right after the trigger. Then repoint later modules to it. That one change makes most scenarios easier to read and debug.

After that, check whether anything in the scenario needs memory between runs. If it does, move that state into a data store or your CRM. Note that Make's documentation says organization and team level custom variables are only available on Pro, Teams, and Enterprise plans, so check your plan before you design around them.

If your scenarios have grown past the point where you trust them, reach out. I build websites and the automations behind them for lead generation, and cleaning up how context flows is often the fastest way to make a fragile workflow reliable. Let's chat.