Tools & Workflows · The same workflow with Make

The same case. A different build.

Request → task · English edition of 25 September 2026 · German text as of 10 September 2026

Make builds workflows as scenarios made of modules. This blueprint uses nine native modules with variables, formula expressions, an iterator and an aggregator. For this comparison the job stays the same: check the request, detect repeats and produce an output you can trace.

Evidence status

The business rule has been measured in a real n8n runtime: seven synthetic requests produce exactly three tasks, one duplicate and three errors, identical field by field to the supplied expected set. The run took place in an isolated container without network access, and a deliberately corrupted copy fails it. It is evidence for the rule behind the workflow, not for the Make implementation. For the Make blueprint, the same test file checks the structure automatically: all nine modules come from Make itself, and the input stored in the blueprint is the same as in the n8n run. Make runs only in the cloud, and our blueprint has not yet been run there. That is why the import and the first test with “Run once” are up to you. The steps and expected outputs are included in the download.

What you need

Your own Make test area and permission to create a new scenario. Check there which modules and execution options your account allows. The free download does not come with a free or unlimited Make plan.

The import and cloud test guide is in German, as is the rest of the package documentation. The blueprint itself does not depend on the language.

Make blueprint (JSON) ↓Import & cloud test (Markdown, in German) ↓

Start in a new scenario

Import the blueprint. Create an empty scenario and choose the blueprint import in the scenario builder. Open make-blueprint.json.
Check the modules. Review the module versions, fields, formulas and mappings documented in the download. An import without error messages is not yet a verified workflow.
Use test data only. Take the supplied synthetic inputs. Do not connect a customer spreadsheet, a real mailbox or any message sending.
Run it once and open the outputs. Use “Run once”. Check the data actually processed on every result branch and compare it with the cloud test procedure.

A fair comparison means testing the same error

What you can see

Normalisation and result mapping sit in readable expressions inside the modules. The result list collects tasks, duplicates and errors. That makes checking easier if you prefer a visual workflow. Whether this specific configuration works correctly only becomes clear when it runs with all test cases.

What you also need to clarify

Plan limits, usage per real case and persistent state depend on your account. A demo with one test list does not prove fail-safe duplicate protection between two runs.

We award no speed score and name no test winner. That would require comparable cloud measurements on the same plan, under the same load and with the same connected systems.

An error branch needs someone at the other end

After each error case, open the aggregated result list and read the record with its ID and status. The supported test contract covers batches of 1 to 100 requests with text fields. An invalid text value must receive an error result. Additional input guards for empty batches, oversized batches and wrong data types are not yet part of this Make version: an empty list can end without any output. So do not use the blueprint unchecked for arbitrary JSON input from elsewhere. If the eventual target system cannot be reached, the request must stay in a readable error store. That is an additional integration test.

Keep your cloud test results separate from the expected data. Record your account and plan, the date, the module versions and any deviations. The shared test pack explains the line between expected and observed results.

Weigh cloud, self-hosting or manual work →