# A social media approval workflow for clients and teams

A social media approval workflow answers three questions: which version is ready, who can authorize it, and what
happens after they say yes. The useful sequence is **draft → review → change → approve → schedule**. A comment that
says “looks good” is not enough if someone can change the post or publish it without the required decision.

For client approval for social posts, keep the copy, media, account, proposed time and feedback together in one review
item. The client should not have to reconstruct the final post from a document, an image folder and a chat thread.

**Checked on October 26, 2026.** The Planable, Later, Hootsuite and Agorapulse descriptions below come from each
vendor's own pages, linked in its section and read on October 26, 2026. This is a public-document guide, not a
hands-on trial. Plans, permissions and editing behavior change; verify the settings in the workspace you will use.

## The five steps

### 1. Draft the complete post

The writer prepares the actual text, media, alt text, destination account and proposed date and time, including the
timezone. An X thread is one review item with all its parts in order. A LinkedIn version is a separate post: approving
an X caption does not automatically approve a rewrite for another network.

Name the authoring account explicitly. “LinkedIn” is not enough when the client has both a personal profile and a
company Page. Include anything someone must do by hand, such as finishing a post in the native app.

### 2. Review what the audience will see

An internal reviewer checks facts, links, spelling, mentions, image crops, accessibility and brand voice. The client
or accountable brand owner checks the message, offer, account and timing. Add a specialist reviewer when the post
actually needs their expertise, rather than routing every ordinary update through every department.

Give concrete feedback on the post itself: “Replace the old launch date in the second image,” not “Please revisit.”
A comment is feedback; approval is a separate decision on the current version.

### 3. Make changes and return the new version

The writer resolves the feedback, keeps the discussion attached to the post and sends the revised version back for
review. If reviewers disagree, the person accountable for the message resolves it before publication.

Decide what your workflow does when approved text, media, account or time changes. If the requirement is approval of
the exact post, the changed version needs a new decision. A product's Approved label does not establish that rule:
some tools let authorized editors change an approved post without restarting the workflow.

### 4. Approve the version, not just the idea

The authorized reviewer approves the final copy, every thread part, media, destination and proposed time. Keep the
reviewer's identity and the decision with that version. For sequential review, an internal sign-off moves the post to
the client; it is not permission to publish before the client stage finishes.

Check whether a tool requires any one approver, every assigned approver or completion of each stage. Also check who
can override the decision. A client review link is useful, but it does not by itself prove publication is blocked.

### 5. Schedule the approved post and follow the result

The authorized publisher or the tool's configured automation schedules only the approved version. Some workflows
schedule automatically at final approval when a time is already set; there is no separate scheduling click.

If approval misses the proposed time, inspect the tool's status before choosing a new time. Do not assume the post
was canceled or that it will never publish late. After publication, record the live link and any failure or mismatch.
A successful approval is not a successful post.

## Who approves what?

Roles can belong to the same person in a small team. The distinction is responsibility, not a requirement to buy more
seats or add more review stages.

| Role | Responsible for | Decision |
|---|---|---|
| Writer or agency producer | Complete draft, assets, platform versions and revisions | Ready for review, not final publishing permission |
| Internal reviewer | Accuracy, voice, links, formatting and accessibility | Internal sign-off or specific changes |
| Client or accountable brand owner | Message, offer, destination account and timing | Final client approval of the current version |
| Specialist, when needed | The particular claim or issue within their remit | Clearance of that issue, not an assumed sign-off on everything |
| Publisher or scheduler | Correct approved version, account, time and live outcome | Release only after the required decisions |
| AI drafting agent | Drafts, uploads, checks and proposed times | Requests approval; does not make the owner's publishing decision |

Before choosing a tool, answer: can the writer publish directly, can an approver edit, can an administrator approve
for someone else, and do edits restart review? Those answers matter more than the number of approval buttons.

## How the common tools do it

### Planable: required and staged approval

Planable's [content approvals guide](https://planable.io/guides/content-approvals-in-planable/) distinguishes No approval,
Optional, Required and Multi-level approval. Optional review does not block publishing. Required, on Pro and
Enterprise, blocks scheduling and publishing until at least one person approves. Multi-level, on Enterprise, moves
through configured stages in order before scheduling is allowed.

Its optional content lock prevents changes after approval until the post is unapproved. Its automatic-scheduling
setting can schedule a dated post when approval completes. Configure those settings to match the version and timing
rule you agreed with the client; do not assume they are enabled.

For roles, client collaboration, plans and agent access, read [Flaghand vs Planable for approval
workflows](/docs/guides/flaghand-vs-planable). Planable is a stronger fit than Flaghand for staged client and legal
review; the full comparison is there rather than repeated here.

### Later: collaboration with publishing exceptions

Later's [approval-workflow page](https://later.com/social-media-approval-workflow/) describes team review and sharing
posts with external reviewers for feedback without a Later account. Collaboration and approval tools start with
Growth. That is useful for gathering client feedback, but not the same as a mandatory gate on every publication.

Its role FAQ says Members cannot approve, yet “their scheduled posts publish regardless of approval status.” It also
says Reviewers' “Publish Without Approval permission can’t be disabled.” If every post needs client sign-off, inspect
those role exceptions before treating a requested review as protection against publication.

### Hootsuite: permission-based approval routing

Hootsuite's [approval setup](https://help.hootsuite.com/s/article/set-up-approvals) documents approval workflows on
Advanced and Enterprise. Limited or Responder permissions, and relevant custom permissions, require approval.
Custom workflows can route reviews sequentially or in parallel; the parallel flow requires every approver to approve.

Its [review instructions](https://help.hootsuite.com/s/article/approve-posts) let authorized reviewers edit, approve
or reject a post. Authors can revise rejected content and resubmit. Once approvals are complete, a post publishes or
stays scheduled as appropriate. If it still needs approval at its publishing time, it goes to the expired queue
instead of publishing.

For clients, distinguish that internal routing from Hootsuite's
[external-approval record](https://help.hootsuite.com/s/article/manage-external-approvals): on Enterprise, a teammate
with Document external approvals permission can mark an external sign-off and enter a note. That article describes
recording a decision obtained elsewhere, not a client clicking a review link in Hootsuite. Do not assume those are
the same workflow.

### Agorapulse: assigned reviewers and shared client calendars

Agorapulse's [submission guide](https://support.agorapulse.com/en/articles/8773562-how-to-send-a-post-for-approval)
lets a post go to internal reviewers or external reviewers connected through a Shared Calendar. Its Everyone must
approve option requires all assigned reviewers. A post lacking the required approval does not publish at its planned
time; the guide warns that approval within five minutes afterward may still let the system retrieve and publish it.

Its [workflow guide](https://support.agorapulse.com/en/articles/10346598-how-to-manage-post-approval-workflows)
places single-step approvals on Professional and Advanced, and multi-step workflows on Custom. Stages can include
internal and external reviewers; an external stage uses reviewers from the same Shared Calendar and cannot mix them
with internal reviewers. Each stage can require all assigned approvals.

The [reviewer guide](https://support.agorapulse.com/en/articles/10353571-how-to-review-a-post-as-an-approver)
explains that external reviewers approve posts assigned to them; requesting changes puts the post in Rejected status
and prevents publication. Owners, Managers and profile Admins can approve for assignees, validating the active stage
in a workflow. The workflow guide also documents an important revision exception: an authorized editor can unlock and
edit a completed post, and it remains Approved. If sign-off must cover the final version, account for that explicitly.

## Approving an AI agent's drafts

Give an agent the writer's job, not the client's decision. It should prepare the post, check it, apply feedback and
request approval for the current version. A proposed time is not a scheduled job. “The AI checked it” is not client
approval, and a prompt telling an agent not to publish is not a server-enforced permission boundary.

Flaghand is built for a person and their agents, not as a replacement for a multi-stage agency review system. The
agent can draft, upload media, check and request approval through the API or MCP. **No API token scope can approve,
schedule or post.** A workspace owner reviews the exact account, content, media and time inside Flaghand and approves
with their passkey. One tap can approve a whole plan. Posting-content changes need a new approval; a successful check
alone authorizes nothing.

Keep the agent's request inside the product's approval flow. If the owner sends it back, the agent reads the note,
revises, checks again and requests approval again. It never approves, schedules, posts or starts a waiting job.
After publication, report the live link and the available verification: Flaghand has limited X read-back, but no
LinkedIn read-back. Neither media processing nor a successful API response proves the live post matches the preview.

For the permission, version-lock and retry checklist, use
[How to let an AI agent post safely](/docs/guides/let-an-ai-agent-post-safely). The
[approval contract](https://app.flaghand.com/docs/approvals) gives the exact owner/agent boundary without repeating it here.

## A workflow to agree with your client

Write down the answers alongside the first plan:

- Which account and platform does each post use, and who publishes it?
- Who reviews internally, and who gives the client's final decision?
- Does any one reviewer suffice, must everyone approve, or are stages sequential?
- What changes need reapproval, and does the configured tool enforce that?
- What happens if the review is late, rejected or changed after approval?
- Where will the live link and any publishing failure be recorded?

Choose a collaboration tool for the client review structure you actually need. Choose Flaghand when the central
requirement is that an AI agent prepares posts but cannot authorize publication. Public sign-up isn't open yet;
[Get access to Flaghand](/schedule) is the current entry point.

[All guides](/docs/guides.md)