The chain reaction nobody saw coming
A freelancer I know built three separate Make.com scenarios for a client. One watched for new Typeform submissions and cleaned up the data. Another took that clean data and enriched it with details from a CRM. A third sent the enriched record to Airtable and fired a Slack notification.
Each scenario was connected to the next via an HTTP module calling a webhook. Scenario A passed data to Scenario B, B passed to C. Neat and modular. The kind of architecture experienced Make users often end up with because it's easier to build and debug smaller scenarios than one massive one.
Then the client's Make plan got downgraded. Scenario B hit a module limit and stopped running. Scenario A kept firing, kept sending data to B's webhook, and kept getting no response. Scenario C never ran. For four days, hundreds of form submissions went nowhere.
Nobody on the team knew Scenario B existed. It wasn't in any documentation. It wasn't named anything that connected it to the others. There was no map.
That's the problem the Dependency Mapper is built to solve.
How Make scenarios call each other (and why you might not realize it)
If your scenarios aren't connected to each other, that's completely fine. Many people run fully independent automations and there's nothing wrong with that. But it's worth understanding how connections happen, because they often get built gradually without anyone stepping back to see the full picture.
The most common way scenarios call each other is through Make's HTTP module. One scenario finishes processing something and uses an HTTP module to send data to a webhook URL. That webhook URL belongs to another scenario, which receives the data and continues the work.
This is a genuinely good pattern. It keeps individual scenarios smaller and focused. It lets you reuse a scenario across multiple workflows. It makes testing easier because you can trigger each piece independently. The downside is that the connections between scenarios exist only in the HTTP module configuration of the calling scenario, not in Make's UI anywhere. There's no view in Make that shows you "these five scenarios form a chain."
Over time, especially in larger Make accounts, it becomes genuinely hard to answer the question: if I delete, modify, or deactivate this scenario, what else is affected?
What the Dependency Mapper does
You upload multiple blueprint files. The tool scans each one for HTTP modules that make outbound calls, extracts the target URLs, and tries to match them against the webhook URLs of the other scenarios you've loaded.
When it finds a match, it draws a connection. Scenario A calls Scenario B. That shows as an arrow. If B also calls C, another arrow. If C calls an HTTP endpoint that isn't one of the scenarios you loaded, that shows up as an unresolved call pointing to an "External" node, so nothing is silently dropped.
The result is an interactive visual graph you can drag around, zoom into, and read. Scenarios that trigger others sit on the left. Scenarios that receive calls sit on the right. Scenarios with no connections to the others you loaded show up too, as isolated nodes.
If your scenarios genuinely aren't connected, the map will show you that clearly. Every scenario is an isolated node with no edges. That's a valid outcome. It confirms there are no hidden dependencies rather than leaving you to wonder.
How to use it
Export the blueprints you want to map
Open each scenario you want to include in Make.com. Click the three dots (...) in the bottom toolbar and select Export Blueprint. Save the .json files. You can start with any subset of your scenarios and add more later.
Load them into the tool
The tool starts with two empty slots. Drop or paste a blueprint into each one. Use the Add scenario button to add more slots as needed. Each slot collapses once it loads and shows the scenario name and module count.
Add webhook URLs for webhook-triggered scenarios
This is the step that enables connection matching. If a scenario is triggered by a webhook, a URL field appears under that slot. Open the scenario in Make, click the webhook module, and copy the webhook URL. Paste it in. Without this, the tool can see outbound HTTP calls but can't match them to their destination scenarios.
Click Build Dependency Map
The tool processes everything and builds the interactive graph. Nodes are draggable. Orange animated edges show confirmed connections. Dashed gray edges point to the External node for calls that don't match any scenario you loaded.
Reading the map
Each node on the graph shows the scenario name, module count, the number of apps it connects to, and a small badge if it has a webhook trigger. You can see at a glance which scenarios are consumers (receiving data), which are producers (sending data out), and which are both.
The unresolved calls section below the graph (when it appears) lists any Make webhook URLs that appeared in HTTP modules but didn't match any scenario you loaded. This is your signal that there are more scenarios in the chain you haven't included yet. Load those blueprints and rebuild the map to see the full picture.
You can drag nodes around to arrange them in a way that matches your mental model of the workflow. The layout algorithm tries to place source scenarios on the left and downstream scenarios on the right, but you're not stuck with that arrangement.
What the tool can't detect
There are some real limitations here that matter for how you interpret the results.
The webhook URL step is manual
Make blueprint files contain a webhook's internal ID number, not its public URL. The public URL lives on Make's servers and isn't exported. So for the tool to match an outbound HTTP call from Scenario A to an inbound webhook in Scenario B, you need to paste Scenario B's webhook URL yourself. One copy-paste per webhook-triggered scenario. Not a huge burden, but it means incomplete results if you skip it.
Only HTTP-based connections are detected
The tool scans HTTP modules for outbound calls. If you're using other methods to pass data between scenarios (unlikely but possible), those won't show up. The HTTP module is by far the most common pattern, so this covers the majority of real-world cross-scenario connections.
Dynamic URLs can't be resolved
If an HTTP module's URL is built dynamically using Make's template syntax (for example, a URL that includes a variable webhook ID pulled from a data store), the tool can't evaluate that expression and won't detect the connection. It only picks up literal URL strings.
It can't tell you about execution order or timing
The map shows which scenarios call which, but it doesn't show whether those calls are synchronous or asynchronous, what happens if a downstream scenario fails, or how long the chain takes. That context still lives in the scenario logic itself.
When you actually need this
Before deleting or heavily modifying a scenario
Before you touch a scenario that might be downstream of something else, load your blueprints and check. A two-minute mapping session can prevent a chain of broken automations you didn't know existed.
When handing off a Make account to a client or new team member
If you've built a system of connected scenarios and someone else needs to maintain it, a dependency map is part of a complete handoff. It answers the question "where does data flow?" without requiring them to open every scenario individually.
When something breaks and you don't know why
If a scenario is failing and you can't figure out why from looking at it alone, checking whether it's a downstream consumer of something else gives you a new place to look. The problem might not be in the scenario that's failing.
When auditing a Make account you inherited
If you've been brought in to work on an existing Make account, loading the blueprints into the Dependency Mapper is one of the fastest ways to understand what's connected to what without spending hours reading through individual scenarios.
And if you map your scenarios and find no connections at all? That's useful too. It confirms your automations are fully independent. You can modify or delete any of them without worrying about taking something else down. That kind of certainty is worth having.
Map your scenarios
Export a few blueprints from Make.com, load them into the tool, and see what's connected. Takes about two minutes.
Open Dependency Mapper