How Do You Add Human Approval Before Zapier or Make Publishes Marketing Content?

Add a recoverable human gate before Zapier or Make publishes content, with record fields, role controls, timeout tests and a worked release example.

Short answer: answer: Split the automation into preparation and release, write a versioned release record between them, and require an authenticated person to approve that exact version before a separate publish action can run. Decline, timeout, changed content and unavailable destination credentials must all stop the release. A notification with an “OK” reply is not an adequate gate unless it creates a durable, attributable approval event.

The common design puts an approval step inside one long automation and assumes “paused” means safe. A retry, edited payload, duplicate webhook or permissive operator can still publish something different from what the reviewer saw.

The opposite design asks a person to inspect every harmless machine action. That creates fatigue. Put the gate immediately before the consequential, externally visible action, after generation and formatting are complete.

The Two-Key Automation Gate

CDM’s Two-Key Automation Gate uses two independent events: a system prepares an immutable release candidate; a named human authorizes that candidate. Our position is: no consequential publishing credential should be reachable from the preparation path. Separation matters more than a polished approval screen.

Key one: prepare a versioned release candidate

The first Zap or Make scenario receives the brief, generates or assembles content, checks required fields and writes a release record to a database. It must not contain the final publishing action or a callable path that bypasses approval.

Use this schema:

Calculate the hash from the normalized payload that will be sent, not merely the source document. Any edit creates a new version and resets status to Pending.

Key two: capture a separate approval event

Zapier’s Human in the Loop can pause a Zap and send a data-collection or approval request. Official guidance says the reviewer needs a Zapier account, may be allowed to edit presented fields, and can approve or decline; later steps show as Filtered until approval. If editing is enabled, hash the approved values after the edit and use exactly those values downstream.

Make’s public documentation describes scenarios, webhooks, roles and incomplete executions, but not a universal native marketing approval primitive equivalent to organizational sign-off. A robust Make design can use an external approval record: scenario A writes Pending; an authenticated app updates it to Approved; scenario B receives a single-use webhook or polls for that approved Release ID and hash.

Do not rely on possession of an unprotected webhook URL as identity. Use platform authentication, short-lived signed tokens or an internal approval system, and log the actor.

Keep permissions asymmetric

Preparation operators may edit content but should not release it. Approvers may decide but should not edit the automation or destination connection. Automation administrators can maintain flows but should not be the default campaign approver.

In Make, team roles vary by plan. Official documentation says lower plans have one team without role management; Teams and higher introduce roles such as Admin, Member, Operator, Monitoring and Guest, while custom roles are Enterprise. Operators can activate or schedule scenarios yet have read-only resource access. Confirm actual privileges and separate teams if resource-level boundaries are insufficient.

In Zapier, restrict edit and connection access using the organization’s available controls, and test with representative accounts. The publishing connection should exist only in the release automation.

Build the setup sequence

1. Define which actions require approval: public publish, paid spend, customer message or data export.
2. Create the release table and allowed status transitions.
3. Build preparation through preview rendering and hash creation.
4. Send the reviewer Release ID, destination, preview, rights and deadline.
5. Capture approve/decline with actor, timestamp and comment.
6. Trigger a separate release path that re-reads the record.
7. Verify status, nonce, hash, time window and destination immediately before publish.
8. Write the returned platform ID and rendered URL; otherwise mark Failed.

Automation can validate mechanical requirements and stop unsafe states. Humans judge claims, context, brand risk and exceptions. Approval expires when content, destination, scheduled time beyond an agreed tolerance, claim evidence or rights scope changes.

Make failure recoverable

Zapier documents run states including Needs review and offers manual replay for errored runs; automatic replay is plan-dependent and can retry several times. Held runs may result from flood protection, app disconnection, task limits or policy restrictions. A replay must not duplicate a publish. Check Release ID and Published platform ID before every attempt.

Make’s incomplete executions are disabled by default and must be enabled to preserve unfinished runs. Retry handlers depend on that setting. Webhooks can execute immediately and scenarios process in parallel by default unless sequential processing is configured. Use an idempotency lock so two approval or webhook events cannot publish twice.

Failure test: seven ways the gate should stop

Test in non-production: decline; no response until timeout; approver lacks access; payload changes after approval; approval arrives twice; destination connection fails; publish succeeds but the status-write fails. The last case is crucial: query the destination by Release ID or platform response before retrying.

Also send two webhooks simultaneously and attempt a release with expired creator rights. The expected outcome is one publish at most, an observable error and a recoverable record. Capture screenshots of the release schema, approval prompt, permissions, stopped run, error history, retry and published verification. This is a verification script, not a claim that CDM ran it in a customer account.

Worked release record

This example is illustrative.

• Release ID: REL-2026-118
• Asset/version: VID-44 / SHA-256 suffix 8d2f
• Destination: Brand LinkedIn page
• Preview: approved rendered video and final caption
• Claim IDs: CLM-1042 and CLM-1051
• Rights: organic social, United Kingdom, through 31 December 2026
• Prepared: Make scenario prepare-social-v4, run 88712
• Approver: Product Marketing Director
• Decision: Approved at 14:22 UTC; no edits
• Nonce: consumed once at release
• Result: platform post ID written after successful response

If the caption changes after 14:22, the hash changes, status returns to Pending and the earlier decision cannot release the new version.

Related guides

• How Do You Build a Campaign Decision Log in HubSpot?
• How Do You Build a Marketing Evidence and Claims Register in Notion?

Frequently asked questions

Does Zapier have a built-in human approval step?

Yes. Zapier’s Human in the Loop feature can pause a Zap, present fields to a reviewer and continue or stop after approval or decline. Reviewers need Zapier accounts, and the request can include a due date and editable data depending on setup. Still bind the decision to a Release ID and content hash.

A built-in step improves usability, but it does not by itself prevent a separate Zap, changed payload or replay from bypassing governance. Test the reviewer experience with the least-privileged role.

Does Make have the same approval feature?

Do not assume feature equivalence. Make documents webhooks, roles, scenario controls and incomplete executions, but a marketing approval should be designed as an explicit record and authenticated event unless the exact installed app provides a verified approval primitive. Separate preparation and release scenarios, then recheck the record before publishing.

The caveat is that organizations may connect Microsoft Approvals, Slack or another system; validate its identity, retention and retry behavior rather than treating any button as proof. Name that external system in the release record.

Can the approver edit content inside the approval request?

Only if the system creates a new approved payload after the edit and publishes that exact payload. Zapier can permit field editing in a Human in the Loop request, so compute or store the final hash after review and invalidate any earlier version. For complex creative, prefer editing in the source system and issuing a new candidate.

The exception is a constrained field such as a scheduled minute, where the approval policy explicitly permits changes within a defined range. Record both submitted and approved values for later reconstruction.

What should happen when approval times out?

The release should expire and remain unpublished. Notify the owner, preserve the pending candidate and require a fresh decision if timing, claims, rights or context could have changed.

Do not interpret silence as approval or automatically extend a creator-rights window. For low-risk internal actions, policy may allow reassignment to a backup approver, but the record must show the new actor and deadline rather than silently bypassing the gate. Track timeouts to expose overloaded or badly designed approval routes. Report repeat delays.

How do we prevent duplicate posts after a retry?

Use Release ID as an idempotency key, store the destination response immediately, and check for an existing platform ID before retrying. Where the destination API supports idempotency, use it too. If publishing succeeds but the local write fails, query the destination or reconciliation log before replay.

Some actions lack a reliable lookup; in that case, route the run to manual review rather than risking a duplicate. Recovery speed should not outrank external correctness. Include the key in logs and destination metadata where supported.

Which errors should stop the automation completely?

Stop on missing approval, mismatched hash, expired decision, unauthorized actor, changed destination, expired rights, unsupported claim evidence, missing publishing credentials and ambiguous prior success. Transient rate limits may be retried under an idempotent policy; substantive content failures may not.

The caveat is platform-specific behavior: document which error codes are safe to replay and verify them against current API guidance. An “automatic retry all errors” setting is not a recovery design. Review the safe-retry table after connector or API updates. Record its owner.

Next decision: Build a modern content supply chain without creating commodity content

Related reading: Design creator content approvals · Correct an unapproved AI-generated claim · Design the contemporary marketing operating system

Sources and research notes

• Zapier, Review a data collection or approval request and Human in the Loop.
• Zapier, Review Zap run statuses and What is replay?.
• Make, Teams and roles and Custom roles.
• Make, Incomplete executions, Webhooks and Scenario settings.

Research checked 26 September 2026. CDM reviewed official documentation but did not run a Zap, Make scenario, webhook or recovery demonstration in a customer account. Feature availability, plan entitlements and connector behavior require staging validation. The worked record is illustrative and security architecture should receive appropriate review.