PlaysbyMoat8
Back to the library
The workflow guideMarketing

Schedule approved social content from one workspace

Connect content preparation and a publishing schedule so approved posts can leave a shared workspace predictably.

5 implementation stepsIntermediate

How this works

Scheduling content is a stateful workflow: an approved draft, a scheduled job and a verified live post are different states. Bind approval to the exact text, media and destination so later edits cannot inherit approval accidentally. Use the publishing service receipt as the basis for follow-up verification.

The assistant coordinates preparation and checking while the configured publishing connector performs the external action. A successful upload or accepted request does not prove publication. Design retries around stable job identifiers and receipt reconciliation so delayed responses do not create duplicate posts.

Before you start

Approved payload

Obtain the exact approved copy, media files and destination account. Record the approving owner and version.

Scheduling policy

Confirm local time zone, publication time and allowed rescheduling behavior, including daylight-saving ambiguity.

Publishing access

Use an already authorized connector and account. If unavailable, prepare a schedule manifest for manual submission.

Prepare the inputs

post_payload
Required

Text, media IDs, links and payload version

Validate media availability, text limits and the exact approved revision.

destination
Required

Platform and stable account ID

Display names alone are insufficient when several accounts share a brand.

schedule
Required

Date, time and IANA time zone

Resolve nonexistent or repeated local times before submission.

approval
Required

Payload identity, account scope and approver record

Changed text, media, destination or timing outside the approval invalidates it.

receipt_store
Required

Prior request IDs and delivery states

Check for existing scheduled or live copies before submitting.

Implementation, step by step

  1. Freeze the approved version

    • Create a manifest of copy, media, destination and time. Use a stable payload fingerprint or version ID.
    • Compare the outgoing payload with its approval and show a preview with the actual destination identity.

    Checkpoint: A specific approved revision is ready for scheduling.

  2. Validate delivery requirements

    • Check supported media dimensions, duration, text length and link rendering against available platform requirements.
    • Convert the agreed local schedule to the connector format while retaining the human-readable time zone.

    Checkpoint: The payload and schedule pass the destination checks.

  3. Submit once within authorization

    • Check for an existing request with the same payload identity. Submit one scheduling request only if publication is authorized.
    • Capture the request ID, provider job ID, accepted time and scheduled time without storing credentials.

    Checkpoint: A receipt or explicit unknown outcome is recorded.

  4. Reconcile scheduled state

    • Read the job by receipt and confirm destination, version and scheduled time. Do not create another job just because processing is slow.
    • For rejected jobs, record the actionable failure and revise only the affected payload with appropriate renewed approval.

    Checkpoint: The record distinguishes scheduled, rejected, processing and unknown states.

  5. Verify publication and hand off

    • After the scheduled time, inspect the provider status and the resulting live post where available. Confirm copy, media and destination.
    • Save the final post reference and actual publication time. If evidence remains unavailable, retain pending verification instead of claiming success.

    Checkpoint: The manifest links the approved revision to the verified post or the unresolved delivery issue.

Decisions along the way

A timeout occurs after submission

Read status using the receipt or idempotency key before any retry.

Approved copy changes before publication

Create a new revision and recheck authorization; do not silently update the scheduled payload.

The requested time is in the past

Ask for a new slot or use an already approved late-publication policy; do not post immediately by default.

What you will produce

publication-manifest.csv

CSV

A state record connecting approval and actual delivery.

Include: payload_id · destination_id · scheduled_time · timezone · job_id · state · post_ref · verified_at

publication-review.md

Markdown

Short handoff for unresolved or rejected posts.

Include: preview_checks · approval_version · failures · next_check · owner

Check the result

  • Match the connector account ID to the intended account, not just its display label.
  • Verify text and media against the approved payload fingerprint.
  • Convert time zones in both directions and inspect the resulting local time.
  • Check for duplicate live or scheduled posts before closing the run.
  • Confirm live status from a receipt or visible post rather than an HTTP success alone.

When something goes wrong

Connector returns processing

Use bounded read-only status checks and record the next check; do not resubmit.

Media upload succeeds but scheduling fails

Retain the reusable media receipt and repair only the failed scheduling step.

Publication is live on the wrong account

Stop further posts, notify the owner with the exact receipt and follow the authorized correction path; do not conceal the mistake.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Schedule the approved announcement tomorrow at 09:00 in the agreed time zone.

Inputs

Synthetic payload V3 targets account A01. Submission returns job J07, then a timeout. A status read says J07 is scheduled with V3 at the correct time.

Expected result

Record scheduled job J07 and perform no second POST. Mark publication unverified until the due-time check finds the resulting post.

Run a small pilot

Start small

Run one low-risk approved post through preview, scheduling and final verification.

Record the baseline

Record manual preparation time and historical wrong-version or duplicate errors where known.

Agree success criteria

Require exact payload/destination agreement and traceable final status before scaling volume.

Stop or revise

Stop repeated submissions when outcomes are unknown or account identity cannot be verified.

Keep the scope clear

  • This skill requires authorization to publish to the specific destination; a draft request alone is insufficient.
  • Do not log access tokens or private account credentials. Preserve operational receipts without unnecessary personal data.

Check before using

Check formatting, time zone, account identity and publication status.

Business activities

  • Create and publish content

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Approved post · Destination account and schedule

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗