build.allanninal.dev

Part 5 of 7 · Social scheduler series ~5 min read

How a post gets approved or held

A review card lands in the owner’s inbox the morning before a post is due. The Tuesday offer is drafted and scheduled for 9am tomorrow. There’s a Review button. What happens when she taps it? The honest answer is “it depends on what she actually did.” This post walks through the three things she can do — approve, hold, send now — and how the sheet, the post’s status, and the audit trail all stay in sync.

Key takeaways

  • Three actions per review: approve (lock it in for its time), hold (pull it back to draft), send now (post immediately).
  • Each action updates the posts sheet via the Sheets API and writes an audit row.
  • Approve books a one-off EventBridge Scheduler send for the exact minute the post is due.
  • Hold cancels any queued send and drops the post back to draft without losing the text.
  • The Review button is an interactive card backed by a Function URL.

Three actions on Review

Three actions on the Review button A diagram showing one input on the left flowing through a small interactive review card, then branching into three action paths. Far left: a "Review card" box showing a typical preview — post text, channels, scheduled time, image thumbnail — with three button placeholders below: Approve, Hold, Send now. The owner taps one button. The middle column shows the three branches. Branch one, Approve: a Function URL Lambda sets the approval flag on the row via the Sheets API, sets the status to queued in the ss-status DynamoDB table, books a one-off EventBridge Scheduler rule for the exact send minute, and writes an approved event to the audit trail. Branch two, Hold: the Function URL Lambda clears the approval flag, cancels any queued one-off Scheduler rule for the post, drops the status back to draft, and keeps the text and image untouched so the owner can edit and re-approve later. Branch three, Send now: the Function URL Lambda sets the status to sending and emits a send event immediately, skipping the wait for the scheduled minute but still running the full format check from Part 4 before anything posts. The right side shows the convergence: every action writes a row to the ss-audit DynamoDB table with timestamp, post id, action, by-user, and notes. A note at the bottom: Hold never deletes a post — it just pulls it back to draft. Nothing is lost, and nothing posts without approval. Review card text, channels, time, image [Approve] [Hold] [Send now] Action 1 Approve • Sheets API sets the approved flag • status → queued • one-off send booked Action 2 Hold • Clear approved flag, cancel queued send • status → draft; text kept untouched Action 3 Send now • status → sending, emit send event • full format check — still runs first Audit trail DynamoDB ss-audit timestamp · post_id action · by-user notes Hold never deletes a post — it pulls it back to draft. Nothing posts without approval.
Fig 5. Three actions per review, three different effects. Approve locks the post in and books its send. Hold drops it back to draft without losing it. Send now posts it immediately, still through the full format check. Every action writes to the audit trail.

Action 1: approve (the most common)

The owner read the Tuesday offer, likes it, and wants it to go out at 9am as planned. She taps Approve. The Review card’s buttons submit to a Function URL Lambda, and three things happen, in order. First, the Sheets API sets the approved flag on the row in the posts sheet, with a small note in the approved_by column naming her and the time. Second, the post’s status in ss-status moves to queued, and a one-off EventBridge Scheduler rule is booked for the exact send minute — 9am Tuesday. Third, an action: approved row is written to ss-audit with the user, the timestamp, and the scheduled time.

At 9am Tuesday the one-off rule fires, the Sender runs the format check, and the post goes out. The owner won’t need to touch it again unless she wants to change something — in which case Hold brings it back.

Action 2: hold (the “not yet”)

Sometimes a post isn’t ready. The offer changed. The image is wrong. The timing no longer makes sense because something else is going on that day. The owner isn’t deleting the post — she just doesn’t want it to go out as-is.

Hold clears the approved flag, cancels any queued one-off Scheduler rule for the post, and drops the status back to draft. The text, the image, the channels, and the scheduled time all stay exactly as they were — nothing is lost. The post simply sits in draft until the owner edits it and approves it again, or changes the time, or decides to drop it. Because Hold cancels the queued send, a held post can’t surprise anyone by going out anyway.

Hold is the safety valve that makes the whole approval model work. Knowing that any queued post can be pulled back at any time, right up until the send minute, is what lets the owner approve posts a day or two ahead without worrying about being locked in.

Action 3: send now (the “right now”)

Sometimes a post can’t wait for its scheduled minute. Something just happened — a sold-out item is back, a weather closure, a last-minute event — and the owner wants it out immediately.

Send now sets the status to sending and emits a send event right away, skipping the wait for the scheduled minute. It does not skip the format check: the post still runs through all four guardrails from Part 4 before anything posts, so a “send now” can still fail cleanly if the caption is too long or the image is wrong. The only thing Send now changes is the timing — it never lowers the bar on what’s allowed to go out.

If a post that was scheduled for later is sent now, its original one-off Scheduler rule is cancelled so it doesn’t fire a second time. The audit row records that it went out early and who pushed it, so the history is clear.

Every action is logged, every action is reversible

The ss-audit table records every approve, hold, and send-now with the user who took the action, the timestamp, and a snapshot of the row before and after. If a post went out that shouldn’t have, or a wrong time slipped in, a quick look at the audit trail shows exactly what changed and who changed it. Holding a post that’s already gone out can’t un-post it — nothing can — but the audit trail at least makes it instantly clear how it happened, so the fix is to delete it on the platform and adjust the template, not to go hunting.

This kind of clear record matters most when more than one person can draft posts. The next time a post goes out at an odd time, the audit trail is the only memory anyone needs to see who approved it and when.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why it’s cheaper than a per-seat scheduling tool.

All posts