Make has a real human-in-the-loop app now. It generates a hosted review page, lets a reviewer approve, adjust, or cancel, and fires a trigger when the decision lands. There’s just one catch: it only executes on the Enterprise plan. If you’re on Free, Core, Pro, or Teams and you want a human approval step in Make.com, you’re building it yourself.
The good news is that the workaround is well understood, and it works. The pattern is to split your scenario in two at the exact moment you want a human to look at something. Scenario one does the work and stops to ask. Scenario two is the approval itself, triggered when you click a link. Make’s own blog post on human-in-the-loop automation recommends exactly this shape (a webhook or data store capturing the decision), but doesn’t show you how to wire it. This post does, including what it costs in operations and where it gets brittle.
Make’s human-in-the-loop app is Enterprise-only
A quick scope check first, so you don’t spend an afternoon on a workaround you don’t need. Make’s native app (“Human in the loop”) ships four modules: Create a review request, Cancel review request, Watch completed reviews, and List reviews. You can even add them to a scenario on any plan. They just won’t run unless your organization is on Enterprise, a limitation independent reviewers have confirmed the hard way.
If you have Enterprise, use it and skip this tutorial. For everyone else, the two-scenario pattern below is the standard answer, and it’s the one Make’s community has converged on across years of forum threads.
The pattern: split your scenario at the approval
For this example, assume a customer emails asking for a refund. Your automation reads the request, looks up the order, drafts the refund and a reply email. You don’t want any of that executing on its own while money is about to move. You want to see it first.
The architecture looks like this:
Scenario one handles everything up to the decision: it watches for refund requests, gathers the order details, drafts the response, saves all of it somewhere with an ID, and sends you an email with two buttons: Approve and Reject. Then it ends. Nothing is pending or sleeping inside Make, the scenario is just done.
Scenario two starts with a webhook, which is just a URL that Make listens on. The Approve and Reject buttons in your email point at that URL. When you click one, scenario two wakes up, reads which button you clicked, fetches the saved record, and either processes the refund or files the rejection.
The human approval step lives in the gap between the two scenarios. While the request sits in your inbox, nothing runs and you aren’t paying for anything.
Scenario one: stop and ask
Build your trigger and processing modules as usual: the mailbox watcher, the order lookup, the AI module drafting the reply if you’re using one.
Then, before the end of the scenario, store the work. Use a Make data store, a Google Sheet, or Airtable, and write one record containing everything scenario two will need: order ID, refund amount, the drafted reply, and a status field set to pending. Give the record an ID, because scenario two will need it to look everything back up.
Put only the ID in the approval links, never the data itself. Long URLs holding drafted text get mangled by email clients, and one community thread settled on the clean version of the pattern: the link carries a record ID and an action, and scenario two re-fetches everything else. Your two links look like this:
https://hook.make.com/your-webhook-id?recordId=ord_4821&action=approve
https://hook.make.com/your-webhook-id?recordId=ord_4821&action=reject
(You’ll get the real webhook URL in a minute, when you build scenario two. Build that first if you prefer; the order doesn’t matter.)
Finish scenario one with an email module (Gmail, Outlook, or plain Email) sending yourself an HTML message: a summary of what’s about to happen, the drafted reply so you can actually review it, and the two links styled as buttons. Send the email and let the scenario end there.
Scenario two: the approval webhook
Create a new scenario and pick Webhooks → Custom webhook as the trigger. Make generates the URL. Copy it into the links in scenario one’s email.
A detail that makes this pattern friendly for non-developers: Make’s webhook merges query parameters straight into the trigger’s output bundle. You don’t need to send JSON or set headers. A plain link click delivers recordId and action as fields you can map like any other module output. To teach Make the structure, run the scenario once while clicking a test link, and the fields appear.
If you’d rather not assemble the approval page yourself, the free Approval Gateway hosts the link and decision page and posts the signed result to your custom webhook.
From the webhook, add three things:
- A router with two paths, one filtered on
action = approve, one onaction = reject. Routers don’t consume operations, so the branch is free. - The work. On the approve path: fetch the record by
recordId, check its status is stillpending, process the refund, send the drafted reply, update the status toapproved. On the reject path: update the status torejected, and optionally notify whoever needs to know. - A Webhook response module at the end of each path. Without it, the person who clicked sees Make’s default response, a bare page reading “Accepted”. With it, you can return a small HTML page saying “Refund approved ✓” or redirect to any page you like. It’s one extra module and it makes the flow feel finished.
The status check in step 2 has to be there. The approval links keep working after you’ve decided, so a second click on a stale email would re-run the refund. Checking pending before acting makes sure the link is single-use.
What an approval costs in operations
Make bills per operation: every module run consumes one, including the webhook trigger receiving your click. (Make’s pricing page has started calling them credits; the help docs still say operations. Same unit.)
Count the pattern for one refund: scenario one spends roughly 3 or 4 operations (trigger, lookup, store, email), and scenario two spends another 3 or 4 when you click (webhook, fetch, update, response, plus the refund and reply modules themselves). Call it 7 to 9 operations per approved request, and a request you never act on costs only scenario one’s share, since an unclicked webhook consumes nothing.
On Make’s Free plan that’s 1,000 operations a month, so the math works fine at low volume. The squeeze arrives with scale and with every additional workflow you put behind an approval, because the approval machinery (store, email, webhook, fetch, update, response) is overhead you rebuild in every scenario pair that needs it, and pay for again on every run. We’ve written before about which decisions actually need a human, and the reality is that the more your automation touches money and customers, the more of these pairs you end up maintaining.
Where the pattern gets brittle
It would be dishonest to leave you with the impression this is set-and-forget. Four things to know before you rely on it:
The approve link is a bearer token. Anyone holding the URL can approve, no login required. Email forwarding is the realistic way this would leak. You can mitigate it by adding an unguessable token to the link when scenario one creates the record and having scenario two validate it against the stored value before acting, but that adds complexity.
Webhooks expire when idle. Make deactivates webhooks that aren’t connected to an active scenario for more than five days, after which clicks return a 410 error. Keep scenario two switched on, even in quiet weeks.
Nobody is watching the clock. If you never click, nothing happens, forever. There’s no timeout and no reminder unless you build a third scenario to scan for stale pending records and nudge you.
Two scenarios drift. Rename a field in the data store and you have two places to update. The pattern’s maintenance cost is minimal but it doubles with every approval-gated workflow you add.
When the workaround is the product
Make isn’t a bad tool. Human approval is just an afterthought on plans below Enterprise, and you’re supplying the missing feature with duct tape and webhooks.
If approvals are occasional in your work, build the pattern above and enjoy it. If reviewing your automation’s decisions is a daily habit, consider a tool where the approval step is the product. In Rills, the pause is a single step in the workflow, and the approve and reject buttons live in a queue on your phone. Every record stays single-use and authenticated without you wiring tokens, and approvals are free: they never consume credits, no matter how many workflows are waiting on you. See it in a demo and compare it with the scenario pair you just built.
Ready to automate your workflows?
AI proposes the action, you approve it, and the record shows who signed off.