Draft-Only Social Content Automation with a Review Gate

Build a draft queue, not an unattended publishing system. Source input is an approved factual note; output is a draft with platform, text, source reference and review status. Current integration actions must be checked in the platform you actually use.

Supplies total 20 in a five-row sample. Travel total 25. No speed improvement was measured. Draft a short post explaining aligned ranges and a missing-category test; do not invent a productivity statistic.

Require platform, text, supporting source and needs_review=true. Reject missing source, unsupported results and an invalid output shape. A valid JSON object still needs a semantic check.

Show the source next to the draft. The reviewer can revise, reject or approve it. A rejected draft must remain unsent. Verify that an approval action cannot accidentally send other queued drafts.

Use synthetic input and a private destination. Simulate provider timeout, duplicated event and rejected draft. Measure manual versus assisted effort on the same sample set. This article supplies a design and checks, not proof of a live publishing integration.

• Human review for tool calls
• Prompting: clear instructions and examples

Use this fictional spreadsheet input; it supplies the five rows mentioned above. No customer data or publishing connection is needed.

row_id,category,amount
1,Supplies,12
2,Travel,10
3,Supplies,8
4,Travel,15
5,Other,4

Supplies is 12 + 8 = 20; Travel is 10 + 15 = 25. A category with no matching row is 0. In a spreadsheet, keep the category and amount ranges aligned. The post may explain this arithmetic; it may not claim measured time savings.

Create a private queue with event_id, source_id, platform, draft_text, review_status and published_at. For this example, use event_id=practice-001 and source_id=sheet-demo-v1. Require review_status=pending on every new draft. A schema check should reject an empty source_id or a draft_text over your chosen limit.

1. Receive one approved source record. Map its stable ID rather than generating a new ID on each retry.
2. Pass only the approved facts to the drafting step. Request text plus the supporting source ID; keep instructions separate from source text.
3. Validate the output and save it to the queue. The drafting step must not possess a publishing credential.
4. Let a reviewer edit or reject the draft with the source visible. A separate approved action can publish only that reviewed record.
5. Before adding any live destination, check the current trigger and action in your Zapier account. This is a workflow design, not an importable Zap or an observed live integration.

Receive practice-001 twice: expect one queue record. Send an invalid JSON response: expect an error record and no publication. Reject the draft: expect review_status=rejected and published_at empty. Retry after a provider timeout: reuse the event ID. Keep the publishing step disconnected until each case behaves as expected.

Try the aligned-range lesson · See Zapier access and alternatives