Integration · Automation
Make scenarios with error handlers and an operations budget
We design Make scenarios as routes you can read: a filter on every branch, an error handler on every module that writes, and an operations estimate before the first module is placed. You know what a run costs and what happens when a step fails.
Make
Automation
Access
Authentication and least-privilege scopes
Connections stored in your Make organisation: OAuth where the app offers it, API keys for the rest
- crm: deals + contacts
- drive: one folder
- webhook: API-key header check
- team: scenario-level access
Connections belong to your organisation, not to us. At handover the scenarios stay where they are and our seat is removed.
Objects
What we read and what we write
Custom webhook queue
Read: YesWrite: No
One queue per webhook, sized against the cap in Limits.
Bundle
Read: YesWrite: Yes
One item moving through a route; each bundle runs every later module once.
Router route + filter
Read: YesWrite: No
Decides which route a bundle takes; a fallback route catches the rest.
Incomplete execution
Read: YesWrite: Yes
Stored by a Retry handler so the run can resume after a fix.
Data store record
Read: YesWrite: Yes
Dedupe keys and small lookup tables kept inside Make.
Records in your apps
Read: YesWrite: Yes
Created or updated through app modules or the HTTP module.
Data flow
System of record and write-back
Make holds bundles only while a scenario runs, plus run logs and any incomplete executions. Your apps stay the systems of record; a data store keeps only keys and small lookups.
- Instant trigger: a custom webhook or an app event starts the scenario.
- Router: filters send each bundle down one route, with a fallback route for anything unmatched.
- Write modules: each carries the error handler chosen for that step.
- Retry handler: a failed bundle becomes an incomplete execution that resumes after the fix.
- Website form
- Shop order event
- CRM
- Accounting tool
- Incomplete executions
Worked example
Make in a build
Sample workflows
What teams build with Make
Pattern 01
Quote requests to CRM deals
A website form creates or updates the contact, opens a deal with the right owner and posts a summary to the sales channel. Incomplete forms take the fallback route for follow-up.
Pattern 02
Order-to-invoice handoff
A paid order creates the invoice in your accounting tool. A failed write becomes an incomplete execution that resumes once the cause is fixed, so no order is invoiced twice or skipped.
Pattern 03
AI summaries of inbound email
New messages go to a model that pulls out the request, the deadline and the sender. The scenario files the summary and flags anything the model was unsure about.
Failure handling
What breaks, and what the build does about it
An app module returns an error
Each write gets its own handler: Retry where the write must happen, Skip for optional enrichment, Rollback or Commit where the app supports transactions.
A burst of webhooks arrives at once
Requests over Make’s webhook rate are refused, so senders that retry recover by themselves. For senders that do not, a small queue in front of Make absorbs the burst.
Operations run higher than planned
Usually an early module returning many bundles. We filter or aggregate as early as possible and review operations per run in the first week.
Fit · Make
When it is the wrong choice
- Data must stay inside your network. Make runs only as a hosted service, which rules it out.
- Each run fans out into many bundles across many modules. Operations multiply, and n8n or code is usually cheaper to run.
- Every change needs unit tests and code review. Blueprints can be exported, but code is easier to test.
Alternatives worth pricing
Self-hosting, custom nodes and code steps when data must stay in your network.
Simple linear automations that a non-technical owner maintains.
n8n, Make, Zapier and custom code against the same criteria.
Where it is used
Related use cases, services and guides
Limits
Limits and common errors
An operation is one module run. A trigger counts once per check, but every bundle it returns runs each later module again, so early bundles multiply the count.
Source: Operations (opens in a new tab) · Make Help Center · accessed
Credits are what you pay with; operations count the activity in your scenarios.
Source: Credits and operations (opens in a new tab) · Make Help Center · accessed
Make processes up to 300 incoming webhook requests per 10-second interval and returns HTTP 429 beyond that. A queue holds up to 667 items per 10,000 monthly credits, with a hard cap of 10,000.
Source: Webhooks (opens in a new tab) · Make Help Center · accessed
The handlers are Retry (stores an incomplete execution for automatic or manual retry), Skip, Resume, Commit and Rollback.
Source: Error handlers (opens in a new tab) · Make Help Center · accessed
Scenarios that start with an instant trigger deactivate after their first error.
Source: Scenario settings (opens in a new tab) · Make Help Center · accessed
Security
Security notes
- Custom webhooks check an API key or shared-secret header in the first filter; requests without it stop there.
- Scenarios that carry personal data run with “Keep data confidential” on, so logs record the run without its payload.
- Connections use the narrowest scopes, live in your organisation and are rotated when someone leaves.
FAQ
Frequently asked questions
How do you estimate Make operations before building a scenario?
We count the modules on each route, multiply by the bundles a trigger returns per run and then by expected runs per month. The estimate sits in the proposal next to the running cost, and we check it against real runs in the first week.
What is the difference between a Make router and a filter?
A router splits one bundle into several routes; a filter on each route decides whether the bundle continues down it. We always add a fallback route, so a bundle that matches nothing is logged instead of dropped.
Can Make scenarios use AI models?
Yes. Make has modules for common model providers and an HTTP module for anything else, including a model you host. The AI step is kept apart from write steps, so its output is checked before it reaches your apps.
Why does a Make scenario switch itself off?
Make deactivates a scenario after repeated errors, and an instant-trigger scenario after its first. Error handlers and alerts on each write mean a failing app is noticed and fixed before Make turns the scenario off.
What happens to our Make scenarios if we stop working with you?
They stay in your Make organisation with your connections. Each scenario is documented, its blueprint is exported to your repository, and our access is removed at handover.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment