At a glance
A filter decides whether data continues along a connection. A router creates several routes, each of which can have its own filter. More than one matching router route can run; changing their order does not make them mutually exclusive. Use a fallback for data matching none of the other routes, and If-else when you need only the first matching path.
In this guide
Worked example: stop a lead from being sent twice
Suppose a hypothetical sales workflow receives a lead with two fields: urgent and estimated value. Route A sends urgent leads to an inbox; route B flags values of at least 500 for a sales follow-up. A lead can satisfy both conditions.
| Example lead | Urgent route | Value route | Fallback |
|---|---|---|---|
| Urgent; value 800 | Matches | Matches | Does not match |
| Not urgent; value 800 | Does not match | Matches | Does not match |
| Not urgent; value 50 | Does not match | Does not match | Matches |
If both branches send the same email, the first lead could receive two messages. Route order alone will not prevent that. Either make the conditions exclusive or use Make’s documented If-else behavior, which selects the first passing condition. This is a logic example, not a run from a tested account.
Understanding Branching: Inline Filters vs. Flow Routers
In Make (formerly Integromat), managing how data travels through your scenario canvas is a foundational architectural decision. Every incoming trigger generates one or more data bundles. How those bundles navigate through subsequent actions determines whether your automation runs cleanly or triggers unneeded downstream actions that inflate your monthly usage.
Building conditional logic in Make relies primarily on two tools: inline filters placed directly on connection lines, and routers selected from the Flow Control toolkit. While beginners often confuse them or attempt to build complex branching solely through stacked routers, each serves a distinct role in data governance. Choosing the correct approach directly impacts maintenance overhead and prevents scenarios from exceeding Make execution limits.
How Filters Control Bundle Flow
An inline filter functions as a gatekeeper between two modules. You configure a filter by clicking directly on the connecting line that links one module to the next. Once open, the configuration panel allows you to name the condition and define validation rules using operands and comparative operators.
When a bundle arrives at a filter, Make inspects its mapped parameters against your defined rules:
- Pass: If the bundle meets the specified criteria, it proceeds directly to the receiving module.
- Terminate: If the bundle fails the criteria, processing halts immediately for that specific bundle. Upstream modules completed prior to the filter still run, but no subsequent modules in that chain are executed.
Make provides a broad spectrum of operators within the filter setup panel. These include existence checks (exists and does not exist), which evaluate whether a specific field in the payload contains data. For example, a scenario monitoring incoming Gmail messages can use an exists operator on an attachments field to ensure that only emails with actual files proceed to a Google Drive upload module. Other built-in operators cover text comparisons, numeric evaluations, date and time rules, and array validations.
How Routers Direct Multi-Branch Scenarios
While an inline filter is binary—either permitting a bundle to advance or stopping it—a router splits the data stream into two or more diverging execution chains. You can insert a router between existing modules by right-clicking their connecting bridge or by selecting the Router module from the Flow Control menu.
A router by itself does not decide where data goes; it creates parallel-looking visual paths. To direct bundles effectively, you place filters on the individual routes extending out of the router. This architecture introduces three critical operational concepts documented by Make’s router documentation:
1. Sequential, Non-Parallel Processing
Visually, a router appears to fire multiple branches at the exact same moment. In reality, Make processes router branches sequentially, never in parallel. The engine must finish executing every module along the first route before it initiates processing on the second route.
Because execution is strictly sequential, order matters. You can manually adjust the execution hierarchy by right-clicking the router module and selecting Order routes. Make provides visual reordering tools, including an optional auto-align feature that rearranges the canvas to visually reflect your chosen sequence. Placing heavier API calls or time-sensitive data updates on earlier routes ensures priority tasks finish before secondary actions commence.
2. The Fallback Route
When routing bundles across multiple conditional paths, edge cases inevitably occur where incoming data fits none of your standard criteria. Make addresses this with a dedicated fallback route option. When you designate a specific branch as a fallback inside its route filter settings, Make marks that branch on the canvas with a distinctive arrow icon.
A fallback route is always executed last. It only processes incoming bundles if none of the preceding routes accepted the data. In practice, fallback branches are ideal for logging unhandled records into a spreadsheet, alerting a team channel on Slack, or cleanly concluding an execution without raising system errors.
3. Whole Branch Management
Complex routers often branch into dozens of interconnected modules. Make simplifies maintenance through branch-level controls. By opening a route menu and clicking Select whole branch, you can instantly highlight, duplicate, or delete all modules downstream from that branch without manually selecting each node.
Comparing Inline Filters and Routers
Choosing between an inline filter and a router depends on whether your scenario follows a single linear pipeline or requires multi-destination dispatching. The table below outlines how each mechanism behaves within a scenario run.
| Capability | Inline Filter | Router Module |
|---|---|---|
| Canvas Placement | Directly on the line between two modules | Inserted as a standalone Flow Control node |
| Path Outcome | Single path; allows or halts bundle progress | Multiple paths; directs data across several module chains |
| Execution Model | Immediate validation before next module | Sequential execution from first route to last route |
| Default Handling | Non-matching bundles are discarded | Matching routes execute; fallback captures unhandled bundles |
| Scenario Complexity | Low; preserves linear, simple layouts | Moderate to high; creates branching canvas structures |
Canvas Limitations and Practical Caveats
While Make’s visual interface makes routing intuitive, builders must navigate several practical workflow constraints detailed in the official documentation:
- No Native Filter Copying: As confirmed in Make’s filtering guide, the standard scenario editor does not natively support copying and pasting filter rules across connections. If you have complex multi-variable conditions, you must reconstruct them manually on each route. A documented workaround involves installing the Make DevTool Chrome extension, opening browser developer tools, and using the Copy Filter utility to transfer configurations between modules.
- Sequential Delays on Downstream Routes: Because routes never run concurrently, a slow API response or high bundle count on Route 1 blocks Route 2 from starting. If your scenario processes bulk records, bottlenecks on early routes will directly delay secondary actions.
- Operation Consumption: Every module that executes across any matching route consumes an operation against your account plan. If you omit filters on your router branches, every single branch will execute for every bundle, rapidly burning through your plan tier. Reviewing your usage strategy under Make pricing plans helps avoid unexpected overage costs.
Which Approach Suits Your Workflow?
When to Use Standalone Inline Filters
- Single-destination workflows: You receive form submissions or webhook payloads and simply want to discard spam or incomplete entries before writing them to a database.
- Selective file handling: You are polling cloud storage or email attachments and only want to process records that meet a specific naming convention or file extension.
- Linear efficiency: Your scenario runs step-by-step from one trigger to one final action, and you need minimal canvas complexity with no branching paths.
When to Use Routers with Branch Filters
- Multi-platform distribution: A new order needs to update an internal CRM, dispatch an alert to Slack, and notify a fulfillment provider when certain criteria are met.
- Categorized routing: Leads must be sorted by geography, budget, or service tier, sending enterprise inquiries down one path and self-serve users down another.
- Exception capturing: You need an explicit safety net to identify and log unhandled data bundles via a fallback route rather than silently discarding them.
Next Steps for Structuring Make Scenarios
To optimize your scenario architecture before deploying into production, follow these configuration steps:
- Audit your trigger payload: Run a test execution of your trigger module to inspect available bundle keys and data formats before writing condition rules.
- Filter early: Place an inline filter immediately after your trigger whenever possible. Terminating invalid bundles before they hit routers or third-party apps saves account operations.
- Order your branches intentionally: If using a router, right-click the node, open the Order routes panel, and arrange routes so critical or high-frequency paths execute ahead of lower-priority actions.
- Assign a fallback: Set up a final route designated as a fallback with an error log or notification module to ensure missing data conditions never go unnoticed.
Why did the wrong route run?
- Several routes ran: check whether the same input satisfies more than one condition. Sequential processing does not mean only one match is used.
- No route ran: compare the actual incoming value with the filter condition, including the selected operator. Check whether a fallback is configured.
- A value is missing: confirm the mapped item exists in the incoming bundle before comparing it.
- You need to reconnect the paths: consult If-else and Merge; changing a router’s visual arrangement does not create that behavior.
For documented filter configuration, refer to Make’s filtering guide. For billing implications, use our separate Make pricing guide.
Sources and further reading
Worked example and If-else distinction added 29 October 2026 using Make’s Router, Filtering, and If-else and Merge documentation. No live-account test is claimed.
Research checked 2026-09-24. Product details can change.