Make.com Human Approval Without Paying for Enterprise

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.

Coming from Relay.app? Read this part first

Make is courting Relay users hard right now. Relay.app is winding down, free accounts on August 15, 2026 and paid on September 14, and Make has put up a migration page offering eligible Relay customers free white-glove migration with engineering help, priority support, and live office hours through the September deadline. That’s a genuinely good offer and worth taking seriously if breadth of integrations is what you need.

It’s also worth noticing what that page doesn’t say. Make’s Relay migration guide covers AI agents, integrations, pricing, and migration logistics, and never mentions human-in-the-loop or approvals once. Which tracks, because the answer is the section above: the native approval app runs on Enterprise only. If the human step is why you were on Relay, the free white-glove migration will move your scenarios and hand you back a platform where the feature you came for is either an Enterprise line item or the workaround in this tutorial.

That’s the trade in plain terms. Relay gave you a human step on every plan, free tier included. Make gives you a better app catalog, a real migration offer, and an approval story that starts at Enterprise or starts at duct tape. Pick knowingly rather than finding out in week three.

Whichever way you go, get your files out first. Nothing imports Relay’s format, so every scenario is a hand rebuild from the JSON and AI-prompt exports, and after your account’s date there’s no archive to ask for. If the rebuild is what’s blocking you, send us the export and we’ll do it for free, then send back a private link so you can watch your own workflow run before you commit to anything.

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 on action = 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 still pending, process the refund, send the drafted reply, update the status to approved. On the reject path: update the status to rejected, 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.

Common questions

Does Make.com have a human approval step like Relay.app?

Make has a native Human in the loop app, but its modules only execute on the Enterprise plan. On Free, Core, Pro, or Teams you build the approval yourself by splitting the scenario in two and wiring approve and reject links to a webhook. Relay gave you a human step on every plan including the free one.

Is Make's Human in the loop app available on the Pro plan?

No. You can add the modules to a scenario on any plan, but they will not run unless your organization is on Enterprise. Independent reviewers have confirmed this the hard way, so check before you design a scenario around it.

Is Make a good replacement for Relay.app?

For integration breadth and visual building, yes, and Make is offering eligible Relay customers free white-glove migration help through September 14, 2026. For approvals specifically it is the weakest of the common destinations, since the native approval app is Enterprise-only and Make's own Relay migration page does not mention approvals at all.

What does a DIY approval step cost in Make operations?

The approval machinery itself consumes operations on every run, because the modules that store the pending record, send the notification, and process the decision each burn a credit whether or not anything was approved. The waiting between the two scenarios is free, since nothing is running while the request sits in your inbox.

Can I import my Relay.app workflows into Make?

Not directly. No platform reads Relay's export format, so you rebuild each scenario by hand. Relay's AI-prompt export is the transferable piece, since it describes each workflow in plain language.