Make, automation you can see

Make, automation you can see

Make, formerly known as Integromat, builds automations on a canvas: you drag modules, connect them with lines, and watch data flow through successive steps. That separates it from tools based on a step list, where a branch is a configuration entry rather than a visible fork.

The difference stops being aesthetic once a scenario carries five conditions and three paths. On a list you must imagine it; on a map you simply see what happens and where data turns.

Scenario, module, and data

A scenario is one automation. It begins with a trigger, meaning a module watching for an event, followed by modules performing actions.

Triggers come in two kinds and that split affects cost. A polling trigger checks the source on a schedule and consumes a credit on every check, even when nothing changed. An instant trigger waits for a notification from the service and consumes a credit only when something actually arrived.

Choosing an instant trigger where one exists can cut usage severalfold. A scenario polling every five minutes performs nearly nine thousand checks a month, most of them finding nothing.

Data passes between modules through references to previous steps' output. Built in functions handle transformations, covering text, dates, arrays, and conditional logic, so simple operations need no code module.

Credits instead of operations

The billing scheme changed and that is the most important thing when planning a budget. Previously it counted operations, where every module run cost one unit. Now it counts credits, and different module types cost differently.

An ordinary module call costs one credit. Modules running code, using language models, or using agent features cost more, sometimes considerably more. That changes the arithmetic of scenarios with artificial intelligence in them.

The practical consequence: you can no longer estimate cost by counting modules in a scenario. You must run it a few times, check actual usage in the history, and multiply by expected frequency.

Three things reduce usage most. The first is a filter placed as early as possible, so the scenario ends at the second module rather than the tenth. The second is batch processing rather than a separate run per item. The third is an instant trigger rather than polling.

Error handling

This is where production scenarios differ from toys, and the part most often skipped. By default an error in a module stops the scenario, and repeated errors switch the automation off.

Every module can take an error handling route with one of several behaviours. Retrying suits transient errors such as a rate limit. Skipping suits cases where one failed item should not stop the rest. Breaking with a stored state lets you resume the scenario after fixing the cause.

The choice depends on what happens on failure. If the scenario sends notifications, skipping is fine. If it posts payments, skipping means silent data loss and stopping everything is better.

Add a route that records the error somewhere a person will see it: a message on a team channel or a row in a spreadsheet. A scenario switched off quietly on Wednesday is usually noticed on Monday.

Iterators, aggregators, and arrays

A module returning a list of items is where scenarios most often start consuming many times the credits they should.

An iterator splits an array into separate runs, so modules after it execute once per element. On an order with twenty line items that means twenty calls to every subsequent module. Sometimes that is necessary; more often it is avoidable.

An aggregator does the reverse: it folds many runs back into one structure. The typical pattern goes like this: an iterator splits the list, an intermediate module processes a single element, an aggregator assembles the result, and only then does one call write the whole thing.

That pair turns twenty spreadsheet writes into one. The credit difference is twentyfold and the result is the same.

Remember too the search module returning many results without an iterator. If you need only the first match, setting the limit to one saves the entire downstream scenario from running again.

Testing and shipping changes

A scenario wired to real data will message a real customer on its first error. A few habits limit that risk.

The first is single runs while building. The run once button executes the scenario one time and shows data entering and leaving every module, so you see what actually passed onward before enabling the schedule.

The second is swapping the recipient during testing. A test address instead of a real one, a test channel instead of the production one, a test spreadsheet instead of the database. It takes a minute and saves explaining a message sent by mistake.

The third is cloning a scenario before a larger change. A copy lets you return to a working version, since the platform offers no change history in the form version control in code accustoms you to.

The fourth is reviewing run history after shipping. The log shows data from every run, so the day after enabling it, check a few random runs rather than waiting for a complaint.

Agents and model modules

The platform added an agent layer where, rather than describing every step, you describe a goal and the available tools and the model decides the order. Alongside it comes a view showing an organisation's entire automation landscape.

The sensible approach separates roles. Steps that must run identically every time stay as ordinary modules. A model goes where judgement about content is needed: classifying a ticket, summarising, extracting data from text.

The reverse order, letting a model decide the sequence of operations on production data, is tempting and risky. An automation should be predictable, and an agent with write access can surprise you.

Check a feature's status before resting a process on it. Some agent capabilities ship as open beta even though marketing pages present them as finished.

Pricing

The prices above apply to annual billing with the base credit allowance. Raising the allowance raises the rate, so real cost depends on usage more than on the chosen tier.

One thing the table alone does not show is worth noting: all three paid plans start from the same allowance of ten thousand credits. They differ only in features, so moving from Core to Pro gains you not a single extra credit. If what you lack is volume rather than variables or error handling, raise the allowance on the cheaper plan instead of changing tier. Annual billing also lowers the rate by around fifteen percent against monthly.

The commonest trap is picking the cheapest plan and exhausting the allowance mid month. Buying credits in the middle costs more than a higher plan from the start, so after a first month of work, measure actual usage and match the tier.

The second thing is run frequency. Lower plans cap how often a scenario may run, which forces a higher tier regardless of credit count when you need reaction within a minute.

Security and access

Automation by nature reaches many systems at once, so one account can touch email, a customer database, and a payment system simultaneously. That is convenient and worth thinking through.

Keep connections to external services as connections rather than as keys typed into module fields. A key in a text field stays in the configuration and in the run history, so anybody with scenario access can see it.

Restrict permissions on the target services to the minimum. A technical account with read access suffices for a reporting scenario, and granting it full rights means a configuration slip can delete data.

Who may edit production scenarios is a separate matter. In team work a scenario changed by one person takes effect immediately for everyone, with no review and no way back. Deciding which scenarios are critical and need agreement is cheaper than explaining why they stopped working.

Review what data passes through the platform too. Run history stores the content of processed records, so with personal data you must check the retention period and whether it matches the requirements your organisation operates under.

Make against the alternatives

Choosing among the first three rows depends on three things: whether you need branching, how many runs a month, and whether data may go outside. For a simple connection between two services the second row's simplicity wins, for a scenario with five conditions the first does, and under a locality requirement the third.

Consider the last row once automation becomes central to a process. A scenario with thirty modules and elaborate error handling is software already, only written in a graphical interface and without tests.

Between the first row and the last sits Pipedream, where a single step is plain Node.js, Python, Go, or Bash code running in the cloud without a server of your own, billed by compute time rather than step count. You get control close to your own code without maintaining infrastructure, and pay for it with the fact that a non technical colleague can no longer amend the flow.

The sensible boundary runs where connecting ready services ends and business logic begins. Moving data from a form into a database and sending a notification is a job for automation. Calculating discounts by rules that change every quarter is a job for code, if only because it can be tested before deployment.

Common mistakes

The first is a filter placed at the end of a scenario. Every module before it consumes credits, including for data that will be discarded anyway.

The second is a polling trigger where an instant one exists. Checking every five minutes for a month is thousands of runs, most finding nothing.

The third is no error handling. A scenario stopped after three failed attempts gets switched off and nobody notices until somebody asks why data stopped arriving.

The fourth is keeping keys in text fields rather than in connections. A key typed straight into a module is visible to anyone with scenario access and stays in the run history.

The fifth is one giant scenario instead of several smaller ones. Thirty modules in one flow make diagnosis hard, and an error in one branch stops everything.

The sixth is no test environment. A scenario wired straight to production data sends messages to real customers or modifies real records on its first error.

FAQ

How does Make differ from Zapier?

Make builds automations on a visual map with visible branches, which suits scenarios carrying many conditions. Zapier has more ready integrations and a simpler linear model, better for connecting two services. At volume Make usually comes out cheaper.

What does Make cost?

The free plan covers around a thousand credits monthly. Paid plans start at nine dollars on annual billing and rise with the credit allowance. Real cost depends on usage, so after a first month check the run history and match the tier.

What are credits?

They are the billing unit that replaced the earlier operations. An ordinary module call costs one credit, while modules with code, language models, and agent features cost more. That is why cost cannot be estimated by counting modules and actual usage must be checked.

Is Make suitable for critical processes?

Yes, provided error handling and stoppage alerts are in place. Without error routes a scenario switches off after a run of failures and nobody notices. For processes touching money, also think through whether skipping a failed item is acceptable.

When is writing your own code better?

When the logic is complex, needs tests, or when a scenario has grown to dozens of modules. An automation that size is software already, only without version control and without tests, so moving it into a repository is often cheaper to maintain.

Documentation sits in the Make help centre, and billing details appear in the plan changes article.