Short answer
Valid human approval authorises an action on a specific version, with verified identity, expiry and one execution. In Make, separate preparation from sending and test rejection and changes; visiting a public link should not constitute approval.
Key verification: Test repeated responses, modified versions, expired approval and unauthenticated review.
Sources and limitationsA human approval in an automation must authorize a specific action on a specific version of the data. Receiving a “yes” in the mail isn't enough if you don't know who responded or what they approved. This guide designs a review gate before sending an automatically generated summary to the client.
Separate preparation from execution
The first flow prepares the draft and creates a review request. Sending to customer occurs after valid approval. Maintain statuses such as pending, approved, rejected, expired and executed. No query error should be interpreted as authorization.
Record request, draft version, final recipient, authorized reviewer and expiration. If the content changes, the previous approval no longer covers the new version. The criterion must be verifiable without depending on the free text of a message.
Documented Make capabilities
Make documents a Human in the Loop app for adding reviews, available on Enterprise and in closed beta for invited customers, according to its official documentation accessed October 3, 2026. It is not presented here as a feature available on any account.
If you don't have access, evaluate a circuit with an authenticated review tool and persistent states. Make documents cross-scenario storage in your data stores . This allows a record to be designed, but does not by itself provide identity of the approver or concurrency control of the entire process.
Original decision table
| Test situation | Expected decision |
|---|---|
| Authorized reviewer approves version 2 | Version 2 can be run once |
| Draft changes to version 3 | Request new revision |
| Request expired | Stop execution and notify the person responsible |
| Response from an unauthorized person | Do not accept approval |
| Two events on the same request | Keep a single authorized execution |
Do not use public-link visits as approval
Do not convert a simple access to a public URL into an authorization. Links may be forwarded and some systems visit them for review. Use an authenticated interaction that shows the version and scope of the action, with the confirmation method provided by the tool.
Maintain traceability of rejections and comments. If the reviewer corrects a figure, redraft the draft and submit it to the version rule. Do not replace a rejected record with an approved one to unblock the flow.
Acceptance criteria
- Test each row of the table with fictional data.
- Check that nothing is sent before approving.
- Simulate version change and expiration.
- Test a repeated event and review the result.
- Verify that you can explain who authorized each submission.
CallsIQ has not installed this circuit in Make. The design requires validating authentication, persistence and execution with the chosen tools. The choice of architecture and the summary of overdue tasks are different guides; here the result is a verifiable authorization.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original resource.
Sources describe terms and capabilities stated by their owners. Proposed protocols and fictional examples do not establish product tests performed by CallsIQ.
- documentationapps.make.com
- data storeshelp.make.com
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
MakeAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.