Human in the loop (HITL) is a deliberate pause in an automated workflow where an authorized person reviews a specific decision or proposed action before the process continues. It is not a requirement to inspect every automated result.
The practical design question is where that pause belongs. Put it after deterministic rules have separated routine work from meaningful exceptions, and before an action that is costly, difficult to reverse, ambiguous, or high impact. For example, route deals that meet documented pricing rules automatically, but pause a deal with an unusual discount before generating or sending its contract.
This guide focuses on workflow architecture rather than a ready-made integration. The payloads and sequences are proposed designs. Make and HubSpot capabilities are described only where official documentation supports them, and account access, permissions, connectors, response capture, and destination behavior still need to be checked before implementation.
Automate the predictable path; pause before an exception becomes a costly or difficult-to-reverse action.
Where should a human checkpoint go?
Place the gate between the decision and the action that decision authorizes. First use fixed rules to identify routine cases and known exceptions. Then send only the cases requiring judgment to an authorized reviewer. Resume the workflow only after it captures and validates an explicit decision.
In a sales workflow, the CRM deal record may be the source of truth. A rule can identify a discount outside the approved range. The reviewer sees the discount, deal value, applicable policy, source record version, and proposed action before a contract is generated. A deal within the documented pricing rules can continue without human inspection.
This creates three operating paths:
- Automated processing: documented rules cover the case, required fields are present, and the action is within policy.
- Exception-based review: a policy exception, uncertain input, or material action is sent to a qualified reviewer.
- Manual handling: the case is too unusual or consequential for the workflow to process safely, so a person owns it from intake to resolution.
Do not add a checkpoint simply because an AI call exists. Assess ambiguity, impact, reversibility, delay tolerance, exception frequency, and whether recorded decisions will help refine the policy. Reviewer capacity is part of the control: a queue that the team cannot service is an unmanaged failure path.
Choose the gate: policy rules first, AI for ambiguity
Use ordinary conditions for facts that can be expressed as policy: amount, currency, discount, account tier, approval authority, record status, required fields, and whether an action has already happened. Make distinguishes standard scenarios based on fixed rules and structured data from AI-agent scenarios that can follow more flexible paths. That distinction is useful for deciding where AI belongs. See Make’s scenario-type comparison.
Use AI for bounded work involving ambiguous or unstructured material. It can summarize a long request, extract a non-standard contract clause, or classify text to help route a case. Treat the result as evidence for a reviewer, not as permission to override a hard rule or perform a high-impact action. Make’s guidance recommends defining tool inputs and outputs, limiting the data supplied, and accounting for unpredictable agent behavior. See Make’s AI Agent best practices and AI agent workflow design.
A useful decision rule is simple: deterministic filters handle known thresholds and eligibility conditions first; only ambiguous or policy-exception cases go to a qualified reviewer. The workflow should also minimize personal data by sending the fields needed for the decision rather than an unrestricted source record.
Design the review request and its decision states
Ask the reviewer to authorize a specific action, not to approve a record or AI result in the abstract. “Approve sending quote Q-1842 for $18,500 with a 12% discount” is actionable. “Approve this deal” is not.
The following is an illustrative payload contract, not a Make-published format. Its row grain is one review request for one proposed action against one source-record version. If the same object is reviewed again, create a new review cycle or request ID.
{
"review_request_id": "rev-2026-00418",
"source_system": "crm",
"source_object_type": "deal",
"source_object_id": "deal-1842",
"source_record_version": "v7",
"proposed_action": "send_quote",
"policy_rule_triggered": "discount_over_limit",
"structured_risk_flags": ["pricing_exception"],
"evidence_links": ["deal-record-link", "pricing-policy-link"],
"reviewer_group": "sales-operations",
"workflow_version": "pricing-review-v2",
"expires_at": "2026-10-18T17:00:00Z"
}Give the reviewer decision-relevant context, not an unbounded data dump. Persist the request ID, source object and version, proposed action, policy trigger, evidence references, reviewer identity, workflow or policy version, expiry, and decision rationale where required.
Keep a mutable current state separate from the decision event when an audit history matters. One event row should represent one reviewer decision for one review request. If a request has several approvers, record each approver action as its own event. Daily approval rates and queue totals belong in separate aggregate records, not in the individual decision table.
Use explicit states such as pending_review, approved, rejected, changes_requested, expired, cancelled, stale, applied, and apply_failed. Reject missing, malformed, or unauthorized responses rather than interpreting them as approval.
Three implementation patterns and their boundaries
The patterns below show where a review can live. The table separates documented product behavior from proposed workflow design. Connector fields, permissions, and destination writes must be verified for the chosen account.
| Trigger and AI job | Validation gate | Approved action | Fallback owner |
|---|---|---|---|
| HubSpot deal enters a configured approval process. AI is not required for documented pricing rules. | Confirm Sales Hub Enterprise, configured criteria, approver permission, and current deal stage. | HubSpot approval state controls progression. Re-check the deal before any separate contract action. | Configured approver or sales operations handles rejection, missing permission, and deals outside the process. |
| Make AI Agent produces a bounded email or content draft for human review. | Check required fields, source references, request identity, decision value, deadline, and content version. | Continue only with the reviewed version. Do not publish a changed draft without another review. | Content owner handles requested changes, high-risk topics, expiry, and invalid responses. |
| Hypothetical refund request reaches Make through an available connector or webhook. AI may summarize reason text but does not decide eligibility. | Check amount, currency, cumulative refunds, current status, reviewer authority, expiry, and duplicate status. | Issue the refund only if the destination supports the required write and the action key has not been applied. | Finance or support handles rejection, stale requests, failed application, and duplicate attempts. |
HubSpot deal-pipeline approval
HubSpot documents deal-pipeline approvals for Sales Hub Enterprise. The feature supports configured criteria, designated approvers, and an all-approver or any-approver mode. Super Admin permissions are required to configure the process, and approvers need the relevant approval permission. HubSpot states that a deal cannot progress beyond the configured approval stage until the applicable requirement is met. See HubSpot’s pipeline approval documentation and HubSpot systems.
Process: a deal enters the configured approval process, HubSpot evaluates its criteria, an authorized approver reviews it in HubSpot, and the native approval state controls progression. Before generating a separate contract, re-check the deal stage, discount, amount, and any other fields used by the approval rule. HubSpot documents exceptions for deals already in a stage when the process is configured and deals that do not enter the configured process. A separate notification does not create HubSpot’s native approval state.
Human review of an AI-agent tool output
Make documents configuring human approval of an AI Agent tool output before the agent continues, including a Slack-based review example. This is distinct from the dedicated Human in the Loop app. Make’s Slack documentation confirms message and event operations, but does not establish that every Slack setup provides native Approve and Request changes buttons. Confirm how the selected workspace captures the response.
Proposed sequence: an approved source triggers the agent, the agent drafts bounded content, the workflow validates required fields and source references, the draft and content version go to a reviewer, and the returned decision is checked against the request ID and allowed values. If the text, recipient list, destination, or source material changes, invalidate the approval and submit the new version. A content owner handles high-risk topics and expired requests.
Refund exception approval, hypothetical
This is a proposed architecture, not a verified connector recipe. Assume a ticketing, payment, or support system sends a request through a confirmed connector or configured webhook. Apply deterministic checks for currency, requested amount, cumulative prior refunds, current status, and whether the action has already happened. AI may summarize unstructured reason text or propose a risk flag, but it must not replace the authorization and duplicate checks.
Proposed sequence: source event, deterministic eligibility and duplicate checks, review request for an exception, explicit approval or rejection, source re-fetch, destination write only if still valid, and durable recording of the operation ID. Use an action key such as refund-7821:issue-refund:v1. Confirm the payment system’s write behavior and idempotency support before describing the workflow as directly supported.
Resume safely: revalidate, deduplicate, and handle failures
An approval authorizes the action and record the reviewer saw, not every later version of that record. After the response, fetch the source again and compare the fields that matter. For a quote, these may include amount and discount. For content, they may include the text, source references, and destination. For a refund, they may include amount, currency, and current refund status.
Re-fetch after the human response, not only before sending the request. The waiting period is when a deal, refund, or draft can change. If a material field differs, mark the decision stale and reopen review instead of applying an old approval.
Design the duplicate control around the downstream action. A source object ID alone is insufficient if the object can be reviewed more than once. Include the review cycle or action version in the idempotency key. For example, a per-refund action might use refund-7821:issue-refund:v1; a per-content publication might use content-271:publish:v3.
Make Data stores support keyed records and add-or-replace operations, but the documentation does not establish race-safe uniqueness across concurrent writers. A lookup followed by creation can race. Where multiple scenarios or writers are possible, use a database-enforced unique constraint or transactional upsert. Sequential webhook processing can be an additional control within an appropriate scenario, not a substitute for durable uniqueness across systems.
Retries and idempotency solve different problems. Make documents error handlers including Retry, but retrying a contract send, refund, email, or CRM update can repeat an external side effect unless the destination supports idempotency or the workflow checks a durable operation key. Use retries for transient errors only, and define owners and next steps for rejection, requested changes, expiry, cancellation, stale data, and failed application.
What Make supports and what to verify before building
Make documents a dedicated Human in the Loop app with modules for creating and cancelling review requests, listing reviews, and watching completed reviews. The documentation states that the app is available on the Enterprise plan and is in closed beta for invited customers. Verify access before selecting this path: Make Human in the Loop app documentation.
Make also documents human approval of an AI Agent tool output before the agent continues, including a Slack-based example. That guidance is not evidence that every Slack configuration has native approval buttons or that it supplies a complete production workflow with validation, audit history, retries, and duplicate protection. Confirm the response mechanism, reviewer identity, workspace permissions, and content binding.
Custom webhooks can trigger Make scenarios, and Data stores can persist keyed records. Webhook queues and execution logs are operational processing tools, not automatically a durable decision history. Make documents that processed webhook data is deleted from the queue and that execution-log retention is limited. If auditability matters, deliberately store the source reference, source version, policy version, reviewer, decision timestamp, rationale, payload or content version, and downstream operation result in a persistent system.
Before committing to a build path, verify plan access, connector coverage, account permissions, reviewer identity, response capture, retention, rate limits, and the destination API’s write and idempotency behavior. For help assessing or building a Make workflow, see Make automations.
Measure whether the checkpoint is working
Establish a baseline, then track review requests, approval and rejection outcomes, median and 95th-percentile time to decision, workload by reviewer or queue, escalations, expired and stale requests, duplicate-action attempts, post-approval source changes, and approval-to-application failures.
Add process-specific outcomes such as rework or policy exceptions caught, but do not assume that human review automatically improves accuracy, reduces bias, or creates compliance or legal defensibility. Reviewer expertise, workload, interface design, authority, and the information shown all affect the result. Human review can also introduce inconsistency, privacy exposure, automation bias, or rubber-stamping.
Keep the measurement grain explicit:
- One review request may contain several approver actions.
- One source object may have several review cycles.
- One AI run may produce several outputs or citations.
- One daily approval-rate summary is an aggregate, not an individual decision event.
Set queue-age and volume limits with the process owner. When a limit is exceeded, redistribute work, escalate to a named group, or use a defined safe fallback. Review routing thresholds at a stated interval and change them based on workload and the outcomes the process is meant to control.