You chose Make because it can genuinely shape data: split an array, loop it, put it back together. That is also why your scenario is now nineteen modules deep, sometimes green when nothing actually happened, and quietly spending credits. We build Make scenarios properly, and we fix the ones that grew.
Built against the tools you already pay for
Make bills by the module run. One credit for the trigger, one for each module below it, every time a bundle passes through. That is fine until an iterator splits a payload of two hundred rows and every module after it runs two hundred times. Nothing in the builder warns you, and the canvas looks identical whether a run costs four credits or four thousand.
The learning curve is the other half of it. Bundles, arrays and collections are three different things, an aggregator has to be pointed back at the module that produced the bundles, the mapping panel only offers fields it has actually seen on a previous run, and storing incomplete executions is a setting somebody has to switch on. Plenty of the Make accounts we are handed were built by someone learning all of that on the job, in production.
None of this is an argument for leaving Make. Of the hosted builders it is the best at shaping awkward data, and for most businesses that matters far more than the price of a credit. It just wants building by somebody who has already made the expensive mistakes.
We decide the trigger first, because an instant webhook and a polling trigger cost different amounts and behave very differently when work arrives in a burst. Routers, filters and error routes then go in as part of the build, rather than being bolted on after the first failure.
We read the execution history and show you which scenarios are actually spending the credits, which is almost never the ones people guess. It is usually a polling trigger checking all night for nothing, or three modules sitting downstream of an iterator that could have been one module sitting upstream of it.
Splitting an array into bundles is the easy half; getting them back into one clean payload, in the right order, in the shape the receiving system wants, is where most scenarios come apart. We use the right aggregator for the job and point it at the module that produced the bundles, so the array functions stop being rebuilt by trial and error.
Every module that touches an outside system gets an error route with a directive chosen deliberately: resume past a harmless miss, break the failed bundle into the incomplete executions queue so it can retry, roll back where a half-finished write is worse than no write. We also switch on incomplete execution storage, which stays off until somebody turns it on, so a failure waits in a queue instead of disappearing.
Where there is no Make app for your system the HTTP module will usually do the job, and for anything you will call repeatedly we build a proper custom app instead. It then behaves like any native module, with its own connection, typed fields and output your team can map from without hand-writing JSON paths.
Much of our Make work starts in an account somebody else built, reading the blueprint to find out why it stops on the third Tuesday of the month. We rename the modules so the canvas can be read, document what we find, and leave you an exported blueprint plus the notes needed to rebuild the connections it does not carry.
Almost always because something upstream started returning more rows. Make charges per module run, so every module after an iterator runs once per item: a feed that grew from twenty rows to four hundred multiplies the whole tail of the scenario by twenty without one change on the canvas. Polling triggers are the other usual culprit, since the module runs on every check whether or not there is anything new to collect. Credits reset on your billing date and do not carry over, and extra credit packs expire at the end of the cycle you bought them in, so buying your way through a spike is money you only get to spend once. We read the execution log, find the modules doing the volume, and usually cut it by filtering earlier and aggregating before the write.
Not by default, and we will say so if it is not worth it. Moving is not an export and an import: a blueprint carries the modules, their settings and the mappings, but not the connections, so every credential is reauthorised by hand, every webhook gets a new URL that the sending system must be told about, and any custom app is rebuilt from scratch. That is real work, and for a business running a handful of scenarios inside its included credits it buys nothing at all. The genuine cases for moving are volume, where per-run billing stops making sense, and data you would rather not route through a third party’s cloud in the first place. If neither describes you, the honest answer is to stay on Make and let us make it cheaper to run.
Usually a bundle count of zero. If a search module finds nothing, or a filter’s condition is not met, the flow simply stops at that point and Make logs the run as successful, because nothing errored. The other common version is an array that came back empty, so the iterator had nothing to split and every module after it sat the run out. Neither shows up as a red execution, which is why this gets discovered weeks later by a customer rather than by you. We put an explicit check wherever the flow can legitimately be empty, alert on it, and switch on incomplete execution storage so anything that does genuinely fail waits to be retried instead of vanishing.
This is the thing Make is properly better at than the simpler per-task tools. An iterator splits a nested array into individual bundles, the aggregators put them back into an array, a table or a block of text depending on what the receiving system expects, and the mapping panel has real functions for dates, arrays and text in between. The catch is that Make only offers you fields it has already seen, so a module has to run once before you can map from it, and a field the API only returns sometimes will not appear in the panel at all. That is exactly how scenarios built by trial and error break later, because the mapping was drawn from one lucky sample. We build against the shapes your API returns on a bad day as well as a good one, and parse JSON against a defined data structure so the panel is honest about what exists.
Make queues them. The webhook accepts each request immediately and holds it until the scenario can take it, which is why Make copes with bursts far better than anything polling on a schedule. Two settings then decide the behaviour: sequential processing, which forces one run at a time and guarantees order, and the cap on how many runs a scenario may start per minute. Sequential is right wherever order matters or the receiving system would otherwise create duplicates, but it has a cost worth knowing about, because one slow call downstream holds up everything behind it and a queue that keeps growing will eventually shed the overflow. We choose per scenario and alert on queue depth, rather than finding out from whoever was at the back of it.
Three situations, and we would rather say so before you pay us. Make is cloud only, with no self-hosted option, so everything you automate passes through Make’s own infrastructure in the region your organisation was created in; if you handle case files, patient records or anything a regulator will later ask about, that is a conversation to have before building rather than after. It is also not built for heavy lifting inside one run: executions have a time ceiling, the built-in data stores are sized to be a lookup table rather than a database, and per-run billing means cost rises with every extra item, with no point where it flattens out. And it is not a queue or a job runner, so if the honest description of the work is ’process a million rows every night’, that belongs elsewhere with Make orchestrating the ends. For a business moving hundreds or a few thousand records a day between real applications it is a very good answer, which is why we are usually arguing to keep it rather than replace it.
Sometimes, and less often than the marketing implies. An agent decides which tool to call and in what order, which earns its place when the input is genuinely ambiguous: classifying a messy inbound email, pulling fields from a supplier PDF laid out differently every time, drafting a reply a human will approve. It is the wrong shape for work that has a rule behind it, because a fixed scenario does the same job the same way every time, can be read on the canvas by whoever inherits it, and costs a predictable number of credits. Agent and AI steps bill dynamically against tokens and processing rather than one credit per module, so a loop that runs a few extra times costs more without anything visibly going wrong. Our default is a deterministic scenario with an AI module at the one step that actually needs judgement, and a real agent only where the task has no fixed path.
Export the blueprint of the one you like least and send it over. We will tell you where the credits are going, what is likely to break next, and whether it wants repairing or rebuilding.
Book a Free Demo