Integrations. Make
Make scenarios that keep working after the person who built them moves on.
The gap between two systems gets filled by a person long before it gets filled by software. An order lands in one tool, somebody retypes it into another, and Make is usually the first thing a business reaches for to stop that. It works. That's the problem. The scenario that saved one afternoon becomes load-bearing, then it multiplies, and two years later dozens of scenarios run the company and nobody can say what half of them do.
We build Make scenarios, and we're running them in production for clients today, carrying leads, jobs, invoices and shipment updates between CRMs, work management platforms and accounting. When we inherit scenarios somebody else built, taking them over is the first step of rebuilding them in your name and on your accounts, not a support contract for what's there. Make stays the glue in every build we do, and your systems stay the record. A scenario that's quietly become the only place a piece of data lives is the first thing we fix.
What we connect
What gets connected between Make and your other systems?
The flows below are the ones we build most often. The scope for your integration names exactly which of them apply, in which direction, and which system wins when the two disagree.
- Leads and form submissions dropped into your CRM the moment they arrive, from a web form, a phone system or a ticketing platform, with the owner and stage already set. Nothing sits in an inbox waiting to be retyped.
- Work orders and jobs carried between a field or facilities system and the platform the team plans in, monday.com or Smartsheet in most of the builds on our record. Every one matched on a stable reference, so the same job can't land twice.
- Invoicing handoffs, where a finished job or a signed order raises the invoice in QuickBooks or your billing system straight from the record that did the work. No Friday afternoon of retyping.
- Shipping and warehouse traffic, with tracking numbers and fulfillment status written back to the system the office actually watches, so shipment questions stop being phone calls.
- Cross-references kept in Make data stores, recording which ID in one system matches which in the other, so every later run finds the match the first run made. Nothing gets matched by name.
- Scenarios other people left behind. We inventory them, then rebuild the ones that matter in a Make organization you own, on connections authorized under your accounts, with names, error routes and alerts from the first day. Nothing about the old build has to be kept alive.
How it works
How does a Make integration work?
A Make scenario is a chain of modules that runs when something triggers it. Where the source system can push, the trigger is a webhook and the flow fires the moment a record changes. Where it can only be polled, the trigger is a schedule. We use the instant trigger wherever a platform offers one, then back it with a periodic sweep of changed records, because webhook deliveries queue while a scenario is down and that queue isn't bottomless. The sweep catches what the queue dropped. A missed event arrives late and still arrives.
A scenario that hits an error stops. That's the default, and it's why so many inherited automations fail silently. We put an error route on every module that writes, with retries and backoff for the calls that fail for a living. Make can park a failed run with the data it was carrying, so you replay it once the cause is fixed. Every write is keyed to a stable reference, so a replay or a repeated webhook can't create a second record. Cross-references between your systems live in a data store, which makes matching a lookup and never a guess at a name.
Then the part most Make accounts never get. Every scenario has a name that says what it does, an owner, and an alert wired to failure and to silence, because a scenario that should have run and didn't is the more dangerous case. Make meters usage in operations, and a loop chewing on bad data burns a surprising amount of it, so we watch the operations count too. You get an inventory. Every scenario, its trigger, and what breaks if you switch it off. An inherited account usually arrives with no such document in sight.
The stakes
What does a bad Make integration cost you?
More than the build, because integrations fail without setting off an alarm. Nobody gets a message saying the numbers stopped agreeing. Somebody notices at month end, and then nobody trusts either system until it is proven again. The failures below are the ones worth designing against from the start.
- One bad record stops the scenario and nothing alerts anyone. The source system keeps accepting orders, the destination hears nothing, and a customer finds the gap before any dashboard does.
- A repeated webhook or a replayed run writes the same record twice. Without a stable key on the write, one paid order becomes two jobs on the board. Somebody ships the duplicate, or schedules it, or invoices it, long before anyone reconciles.
- Sprawl. Dozens of scenarios with default names, a few of them dead, two writing the same field for different reasons, and the person who understood them gone. Nobody dares switch anything off, and every new fix adds one more scenario to the pile.
The order of work
What happens, in what order, on a Make integration?
In this order, every time. The mapping comes before the code, and the reconciliation comes before we call it done. Nothing here is a date. The sequence is fixed, and the runway is set in your written scope once we have seen your actual data.
- 01
Write the flow down first
The canvas makes it tempting to design by dragging modules around. We write the flow down before opening the editor. Which system announces the change, which fields cross, what matches a record on the other side, and which side wins when both got edited. The matching key gets settled here. A scenario that matches on company names when it should match on IDs is a duplicate factory.
- 02
Build the error routes with the happy path
Every module that writes gets an error route the day it's added. Flaky calls retry with backoff. A run that still fails gets parked with its data for replay, and each write carries a stable reference, so the replay can't double up. Cross-references between the two systems go into a data store, and every later run finds the match the first run made.
- 03
Force the failures before the schedule goes on
The scenario runs by hand against copies of real records first, and we pick the awkward ones. A missing email. A renamed company. A webhook delivered twice, and a destination that refuses the write. We check that a failed run parks itself for replay and doesn't half finish, and that the duplicate delivery changes nothing at all. Only then does the webhook or the schedule go live.
- 04
Turn it on with an alarm attached
Activation is where monitoring starts. Failures alert a person with the run attached. So does silence, because a scenario that should run every morning and hasn't is the failure nobody reports. We watch the operations count as well. A loop on bad data spends it fast, and a quiet climb in usage usually means a flow has gone wrong.
- 05
Leave a map, and leave it in your name
Every scenario is named for what it does, sorted into folders, and listed in an inventory that records its trigger, the systems it touches, and what breaks if it stops. Blueprint exports live in your repository, so the logic stays readable outside Make. The organization, the connections and the scenarios are all yours. Remove our access and nothing about how they run changes.
Limits
What we will not do
Cheaper to hear now than to discover halfway through. If one of these is what you are actually after, we will say so on the first call rather than take the work.
- We won't use a Make data store as your database. It's the right place for cross-references and sync state, and the wrong place for the only copy of anything. If a record matters, it lives in one of your systems, where it gets backed up, queried, and kept when a scenario is deleted.
- We won't leave a scenario running without an error route and an alert. A flow that stops silently is worse than no flow at all, because everyone keeps believing it works. If a scenario's worth turning on, it's worth being told when it stops.
- We won't keep patching a scenario that has outgrown Make. When the volume, the branching or the operations bill says a flow belongs in code you own, we'll say so and scope the replacement. The patch would be the easier sale. We'll still say it.
Questions
What people ask about Make integrations
Is Make the same thing as Integromat?
Yes. Integromat renamed itself Make in 2022 and the product carried on underneath. Scenarios, modules, webhooks and data stores all work the way they did, with years of development since. If you've got an old Integromat organization still running, it's the same platform and we can work on it.
When is Make the right choice, and when should we not use it?
Make is right when two systems each hold part of a record and a person could describe the flow between them in a few sentences. Watch for a new row, look up the match, write the result, tell someone if it failed. It's the wrong choice for logic your product depends on, for very high volume, and for flows so branched the canvas stops being readable. Our shorthand is glue versus load-bearing wall. Make is excellent glue. When a flow becomes a wall, it deserves real code.
Someone built our scenarios and left. Can you take them over?
Yes, as the start of a rebuild, not as ongoing support for what's there. We begin with an inventory of every scenario, what triggers it, what it touches, and whether it still runs, because most sprawling accounts have several that are dead and one doing something important nobody remembers. Then the ones that matter get rebuilt in a Make organization you own, on connections authorized under your accounts, with names, error routes and alerts in place before any logic changes. If what you want is somebody to keep the old scenarios running exactly as they are, that's a job for whoever built them or your own IT, and we'll say so on the call.
What happens when a scenario fails halfway through a run?
That depends entirely on how it was built, which is why we build for it. Make can store a failed run together with the data it was carrying, so you replay it once the cause is fixed and nothing is lost. Error routes on each writing step decide whether to retry, skip the one bad record, or stop, and every write is keyed so a replay can't create a duplicate. Either way a person gets alerted. What we design against is the scenario that stops quietly while the queue grows.
Whose Make account does this run in?
Yours. The scenarios live in a Make organization you own, the connections to your other systems are authorized under your accounts, and we work as a member you can remove whenever you want. Blueprint exports of every scenario sit in your repository too, so the logic stays readable outside Make. Nothing about the setup needs us to stay involved for it to keep running.
Our other system can't send webhooks. Does that matter?
No. It just changes the trigger. Make can run a scenario on a schedule, so a system that can't push gets polled for whatever changed since the last run, matched on a modified date or an ID watermark. Plenty of platforms have no real webhook support and can still call a URL from their own automation rules, and a Make webhook address works fine as that URL. The scope records which trigger each flow uses and how fast a change genuinely needs to travel. Most flows that claim to need instant sync are perfectly happy at every few minutes.
What is scenario sprawl and how do you keep it from happening to us?
Sprawl is what an account looks like after two years of quick favors. Dozens of scenarios with default names, no owner, some switched off and never deleted, two of them quietly writing the same field for different reasons. The cure is boring discipline. One scenario per job, a name that says what it does, folders by system, an inventory listing every trigger and every field written, and a periodic pass that deletes what's dead. You keep that inventory as a document. Inherited accounts almost always arrive without one.
What happens when we outgrow Make?
You move the heavy flow into code you own and keep Make for the light ones. The signs are consistent. The operations count climbs, runs queue behind each other, or the canvas has grown too branched to change safely. The matching keys, the field mappings and the failure handling were all written down at the start, so whoever builds the replacement works from a documented flow and never has to reverse-engineer a diagram. Treat Make as a stage you pass through. That's how we recommend buying it.
Related
Where this fits
An integration is rarely the whole job. Usually it is one part of a CRM, an operations system, or a client portal that needs Make to agree with it.
Tell us which two systems disagree
Book a strategy call, or send a short note about what gets retyped today and where the numbers stop matching.