Automate Your AI Content Workflow in Make With a Human Approval Step

Maya Okafor's manual content engine works. Each week a Ready row on her board becomes a draft, she edits and approves it, and the post goes out.

What costs her now is the copying: brief into the assistant, draft into a document, link back into the sheet, approved text into the scheduler. Each paste is a chance to send version 1 after she approved version 2.

This part of the build automates the copying and keeps the decision with her. You'll get the spec for 2 Make scenarios, 1 that turns Ready rows into drafts and 1 that hands over approved versions, plus 6 test records covering an unapproved row, a repeat run, a draft changed after approval and a receipt that fails to save.

It's a build spec and test plan, written from Make's documentation as checked on October 30, 2026. Build it against a test copy of your board and run all 6 tests before it touches live posts. Maya and her consultancy, Ridgeline Ops, are illustrative, and her board comes from part 1, building your own AI content engine.

Jump to the free Make Content Automation Build Guide

AI content automation in Make: create drafts from Ready rows

AI content automation in Make works best as 2 separate scenarios, and the first one only drafts. It runs on a schedule, searches the board for rows at Ready, locks each one, sends the brief to an AI module, saves the draft as a Google Doc and moves the row to Review. Nothing it produces can reach a scheduler.

Why a scheduled status search

Make's Google Sheets app has a Watch New Rows trigger, which its documentation says "triggers when a new row is added". Maya's rows are created at Idea and reach Ready days later, so a new-row trigger fires too early. Its description also warns that "if a sheet contains a blank row, Make doesn't process all subsequent rows."

Search Rows "returns results matching the given criteria", and its Filter field accepts AND and OR conditions. Run on a schedule, it finds each row whenever its status reaches Ready.

The board columns the scenarios use

Part 1's board gains 5 columns. Content IDs stay stable, so every log line, alert and receipt points back to 1 record.

The statuses become Idea, Ready, Drafting, Review, Approved, Handing over, Handed over and Published.

Scenario A: source to draft

Step 3 is the lock. A row at Drafting can't match step 2's filter, so a slow run never drafts the same brief twice.

For step 5, pick the AI provider you already use and confirm its module in your account. Make's Anthropic Claude app, for example, lists a Simple Text Prompt module that lets you "select a model and enter your prompt"; the voice pack from part 2 goes in that prompt.

If anything after step 3 fails, the row stays at Drafting. Treat a row that has sat at Drafting for 2 hours as a failed run: check the scenario's history, fix the cause and set the row back to Ready.

Add a separate approval and handover process

Approval stays a human act recorded in 2 cells. Maya reads a draft version, types that number into Approved version and sets the status to Approved. Scenario B then hands over a row only when its approved version matches its current draft version and no receipt exists yet, and it records the scheduler's receipt on the row.

How Maya approves

She edits the draft document in place, and any change to the words after review means raising Draft version by 1. When she's happy, she types the version she read into Approved version. If she edits again later, Draft version moves ahead of Approved version and Scenario B sends the row back to Review. The check depends on that habit: a word changed without raising Draft version would go out as approved, so she raises the number before she types.

Deciding what deserves a slot on the board stays a strategy job, covered in the AuthorityOS guide to personal brand content strategy.

The destination: a scheduler with a documented scheduling action

Maya's posts go to Hootsuite, because Make documents the 3 modules this design needs. Schedule a Message "schedules a message to be automatically posted on selected social media profiles (excluding Pinterest) at a specified time." Get a Message retrieves a specific message, and List Outbound Messages "fetches messages that are either scheduled to be sent or have already been sent."

The last 2 let Maya check the destination when a run fails. Any scheduler with a create-scheduled-post module and a lookup module fits the same design, so check its Make module list before you choose.

Scenario B: approved-version handover

Make's router documentation says "a fallback route processes data that doesn't fit the condition of all other routes" and that routes run in sequence, so route 2 catches every Approved row that route 1 rejects.

3 safeguards stop a double post. Step 4 moves the row out of Approved before the scheduler is called, so the next run's search can't return it. Route 1 also requires an empty receipt, using the Not exists operator, which Make's filter documentation says "permits only those bundles where a specific item is not filled in." Finally, steps 6 and 7 send every failure to Maya with automatic retries off, so nothing reaches the scheduler a second time until she has checked it.

When the post is scheduled but the receipt doesn't save

This is the failure that creates duplicates in a careless build. Suppose the scheduler accepts RL-10, then step 7's sheet write fails, so the board has no receipt. The path:

1. The row stays at Handing over, which step 2's filter ignores, so the next run leaves it alone.
2. Maya gets the alert email with the content ID and the message ID the scheduler returned.
3. Make's Retry error handler stores an incomplete execution. Make's docs say "you have to enable incomplete executions in scenario settings" first, and with Automatically complete execution set to No, the execution waits for her.
4. She checks the destination before anything else, running Get a Message with the message ID from the alert, or opening Hootsuite's scheduled posts to look for RL-10 at its publish time.
5. If the post is there, she retries. Make's docs say a retry "runs the incomplete execution again, starting with the module that caused the error", so only the receipt write runs and the scheduler isn't called twice. A retry keeps the module settings from when the error happened, so if a setting caused it (a lost sheet permission, say), she fixes step 7 in the execution's Details view, saves it and clicks Run once, which starts at the same module with the original input.
6. If the post isn't there, she deletes the incomplete execution, so a later retry can't record a receipt for a missing post, and sets the row back to Approved for the next run.

A failure at step 6 itself needs the same care. Make automatically retries incomplete executions caused by a ConnectionError, RateLimitError or ModuleTimeoutError, starting with the module that failed, so a scheduler call that timed out after Hootsuite saved the message could post twice. Step 6's error route prevents that, because Make retries a Retry handler's executions on its own only when automatic completion is on.

For a step 6 alert, Maya runs List Outbound Messages first. If the post is there, she deletes the incomplete execution, pastes its message ID into Handover receipt and sets the row to Handed over; if it isn't, she retries. A row that sits at Handing over for 2 hours with no alert means an earlier step failed, so she checks Hootsuite the same way before setting it back to Approved.

Test repeat runs, failures and edits after approval

Testing this build means setting up 6 test records on a copy of the board, running them through both scenarios, and comparing the results with what should happen. Each row gives the content ID, versions, expected status and receipt, and the scheduler check. Add an Observed column and fill it in as you run each test, and point step 6 at a test social profile, or delete each test message in Hootsuite once its check passes.

For test 6, connect step 7 to a Google account with view-only access to the test board, so the write fails after the scheduler step succeeds. Then finish the test: confirm RL-10 is in Hootsuite, open the incomplete execution's Details, switch step 7 to the editing account, save and click Run once. Check that the receipt saves while the scheduler still shows 1 message. Use Run once here, because Make runs a plain retry "with the same module settings as when the error happened" and it would hit the view-only account again.

Edits after handover

Once a post is handed over, the board stops being the place to change it. If Maya spots a typo in RL-5 after handover, she edits or deletes the scheduled message in Hootsuite and records the change in the Automation note. Scenario B won't resend RL-5, because its status is Handed over and its receipt exists.

After the tests pass

Export the scenario blueprints only after all 6 tests pass, and keep credentials and client material out of anything you share. The Make Content Automation Build Guide follows the same rule: it ships only once its setup steps and test records match a build that has passed all 6.

Build Scenario A first and let it run for a week before adding Scenario B; the drafting half carries little risk, and a week of rows at Review shows whether your briefs hold up without you there. Then run the 6 tests, point Scenario B at the live board, and use part 5, measuring your AI content engine, to see what the automation changed.

See AOS membership from $27/month

Get the free Make Content Automation Build Guide