# Content approval: what to review before publishing

> Agree who decides, which version they review and how the decision is recorded. Includes a change-review matrix and an editable approval log.


**Content approval is the review in which an authorised person accepts a specific version for publication.** A social media approval workflow defines what that person receives, when they respond and how changes and decisions are recorded. The outcome should make it possible to identify exactly what may be published.

## Define what approved means

Agree on the review scope before production. It may cover the caption, video or image, offer details, destination account, link and date. Identify who verifies facts and who makes the final decision. In a small team, that may be one person; elsewhere, business, content and brand reviewers handle different aspects.

An “Approved” status has limited value if you cannot connect it to a version. Record the post identifier, version reviewed, decision-maker, date and publishing conditions. If someone approves only the caption, leave the image pending rather than treating the entire post as ready.

These are proposed editorial operating criteria. Adapt them to your client agreement and the tools available. To establish responsibilities and access first, use [client onboarding](/en/guides/social-media-client-onboarding/) and [team roles and permissions](/en/guides/social-media-team-roles-permissions/).

## Send something the reviewer can assess

The reviewer needs to see the content and understand the decision you are asking for. Provide the complete caption, associated media, destination account and offer context. Attach sources for prices, dates or conditions when they need checking. A cropped screenshot may leave out an important condition.

Group feedback by post and ask for actionable changes. “I’m not convinced” identifies a difference in judgement; clarify what the reader should understand or which fact is missing. “This price is for a different package” identifies something checkable. The producer can correct it and explain the change.

**A review request with a clear scope**

**Incomplete request**

Is this okay?

**Scoped request**

Review version 3 of the carousel and caption for the agreed account. Confirm the price, media and link. For changes, identify the slide or sentence involved; we need your decision before the scheduling deadline.

*Fictional editorial example. Deadlines and owners are agreed with the team; the wording does not imply that a platform enforces this process.*

## Close a round of feedback

The person preparing the post gathers feedback, resolves conflicting requests with the approver and submits an identified new version. The next review should make clear what changed and what remains unresolved. Avoid replacing an approved file with another under the same name without preserving a reference to the previous version.

In the fictional **North Studio** example, the team prepares a carousel for an in-person workshop. The business reviewer confirms location and date, the content reviewer checks clarity, and the designated approver accepts version 3, including the caption and booking link. That record closes review of the complete post. A positive comment about the cover would not approve the workshop’s conditions.

The [approval-log CSV](/blogs/research-next-four/approval-en.csv) demonstrates that case and the fields needed to document a post. Keep one row per version and review aspect. Start with a few fields and add detail when your team needs greater traceability. It contains no credentials or real customer data.

## Decide which changes need another review

Agree on the criteria before an urgent change arrives. A corrected price, replacement image or new destination can alter what the reviewer accepted. Ask for review of the affected aspects and retain the others as references. An editorial rule should not be presented as an automatic platform feature.

| Change | What it may affect | Proposed action |
| --- | --- | --- |
| Price, date or condition | Accuracy of the accepted offer. | Check the current source and request approval of the corrected version. |
| Image or video segment | The scene, usage rights or meaning of the message. | Show the replacement media and review the affected combination. |
| Link or account | The action’s destination and the audience receiving the post. | Check the destination and confirm the change with its owner. |
| Publishing time | Offer validity and the calendar agreement. | Confirm whether conditions still hold; review according to the team’s agreement. |
| Wording | The text’s meaning, tone or claim. | Record the change and check whether it alters the approval before proceeding. |

## When the reviewer does not respond

Set a review deadline that allows time for production, changes and scheduling. Agree who replaces an unavailable approver and how a blocker is escalated. When the deadline passes, record the missing decision and propose a new date. This template recommends keeping publication blocked until an explicit decision arrives.

Later, review how many posts needed another round, which remained blocked and how much time passed between request and decision. Define the start and end of that interval and separate waiting from production time. These records help reveal missing information; they do not establish that someone is a poor performer or that a tool automatically shortens review time.

## Where HeyMark fits

HeyMark lets your team comment and upload versions directly on the post, alongside its status, date and owner. Its public offering includes an approval link. These capabilities are described in [how HeyMark works](/en/#product). Your review structure, deadline and decision-maker remain team agreements.

An assistant connected through MCP can read context, activity and internal comments within your permissions. Asking it to summarise outstanding questions helps prepare a review; that does not record someone else’s approval. The [HeyMark MCP](/en/mcp/) describes its scope and available actions.

#### Prepare a post for review

```text
Post: [identifier]. Version: [reference]. Reviewer and scope: [role and aspects]. Planned date: [date]. Review the content, internal comments and activity you can access. Summarise changes, facts needing confirmation and outstanding decisions, with sources. Distinguish feedback from explicit approval. Identify missing versions or decisions. Do not approve for someone else, schedule or publish.
```

## A checkable end to the review

Before proceeding, identify the version, accepted scope, decision-maker and outstanding items. Resolve anything unclear with the team. The template and case are HeyMark’s editorial work; they describe neither actual customer results nor automatic product rules. The cover is an AI-generated illustration.

## Plan your next post in HeyMark.

Keep the idea, review the draft with your team, and see how it performed in the accounts you connected.

[Start free](https://app.heymark.ai) · [See how it works](https://heymark.ai/en/#product)

## Developer and agent resources

- [HeyMark MCP documentation](https://heymark.ai/en/mcp/)
- [llms.txt](https://heymark.ai/llms.txt)
- [Full site content for language models](https://heymark.ai/llms-full.txt)
- MCP protocol endpoint: `POST https://mcp.heymark.ai`
- OAuth protected-resource metadata: [/.well-known/oauth-protected-resource](https://mcp.heymark.ai/.well-known/oauth-protected-resource)
- MCP server card: [/server-card](https://mcp.heymark.ai/server-card)