Most teams run approval in a separate tool. A Trello card next to the post, or a spreadsheet of captions, or an email thread the wrong person replied to. Comments drift away from the draft. By the time the post publishes, no one is sure which version got the green light.
Maeve puts the approval on the post itself. Pick approvers from the workspace. Set whether one is enough or all must agree. The post sits as Pending while the team reads it, then Approved or Rejected. Once approved, it moves into the schedule with the decision kept on record.
Most approval tools hold a card and a thread. The caption and the schedule are somewhere else.
Maeve holds the approval on the draft itself. Approvers, policy, comments, and decision all sit on the same record, with a Pending pill on the card.
Internal sign-off is one of four routing modes. The other three live in Client Reviews.
Per-post selection
Pick the teammates who need to sign off. Approvers come from workspace members with approval access. The list is per-post, not a global setting.
Per request
One approver is enough on Any. Every selected approver has to agree on All. The policy is enforced server-side, so the post can't move forward without it.
Pill on the card
While the team reads it, the post shows Pending. The same pill sits on the Board card. Once the policy is met, the post flips to Approved or Rejected.
Internal or external
Reviewers comment on the post they're reading, attach an image, or leave one of five reactions. Visibility is internal-only by default, with an option to share the same thread externally.
Approval History view
Approval history keeps the version stamp and the per-approver decisions. So when someone asks what got signed off, the answer is on file.
Same post, no re-typing
Once the policy is met, the post moves into the publishing queue. Nothing gets re-typed into another system.
Send a draft into approval from the publishing surface. The same post that holds the caption, media, and platform settings carries the approval request.
Choose teammates from the workspace members who have approval access. The list is per-post. No global approver setting that goes stale a month later.
On Any, one approval is enough. On All, every selected approver has to agree. The policy is enforced server-side.
Each approval shows in the policy progress (1 of 3, 2 of 3, and so on). Once the policy is met, the post can move on.
Reject and the post returns to drafting. Add a reason if you want one on the record. The decision stays in approval history either way.
The post status flips to pending_approval, then to approved or rejected. The Board card and the Calendar tile read from the same state.
Reviewers comment on the same post they're reading. Threads stay attached to the draft, not floating somewhere else, so the next round of edits can see what was asked for.
Five reactions on the comment thread: thumbs up, heart, laugh, party, eyes. For when a teammate just needs to say 'noted' without typing it.
Drop a screenshot or a marked-up reference into the thread. The image stays with the comment, not in a separate inbox.
Each comment is internal-only by default. Mark it external when the same thread should reach the client review side. The internal notes never leak through.
Internal approvals carry a content hash for the draft as it was when sent for review. Edits change the hash, so a fresh round picks up the new version cleanly.
Resolved records sit in Approval History. Each one shows the approvers, what they decided, when, and the outcome (approved, rejected, withdrawn, admin overridden). One audit trail per workspace.
On internal_client mode, internal approval is the gate that opens client review. Once the team approves, the post is ready for the batch to go out.
Approved posts keep their scheduled time and enter the publishing queue. The decision, the version stamp, and the schedule stay on the same draft.
Approvals is the sign-off surface. The Board, Calendar, Composer, and Workbench work the same posts in different shapes. Same post, different shape.
The internal sign-off surface inside an Maeve workspace. The team picks approvers per post, sets a policy, leaves comments, and decides Approve or Reject. The post sits as Pending until the policy is met, then moves on with the decision attached to the draft.
Software that holds a post in a Pending state while the right people sign off. The point is to put the decision, the comments, and the version stamp on the post itself instead of running approval through email and Slack on the side.
Pick the workspace teammates who need to sign off. Choose Any (one approval is enough) or All (everyone has to agree). Send the request from the post. Approvers see Pending in their queue, read the post, and approve or reject. The post moves on once the policy is met.
Workspace members who have approval access. Role gating is server-side, so you can pick from the right list without checking permissions in your head. The list is per-post.
Both work. On Any, one approval is enough and the post moves on. On All, every selected approver has to agree before the policy is met. Set per request.
The post returns to drafting with the rejection on record. A reason is optional. Approval history keeps the rejection so you know what was decided and when, even after the post gets edited and resubmitted.
Up to you. The approver list is whatever you set when you send the request. Most teams don't put the requester on it, but the workflow doesn't stop you.
An edit changes the content hash on the draft. The next round of approval sees the new version. Earlier decisions stay in approval history with their own hash, so you can tell what got approved and what got edited after.
Approvals is for the team signing off inside the workspace. Client Reviews is the no-login surface for the people outside it. Clients open a per-batch link, identify with the email you invited, and decide without an Maeve account. Run either on its own, or run team-then-client (the internal_client mode) where the team approves first and the client review batch goes out after.
Approval History under the workspace. Every resolved approval has the approvers, their decisions, the timestamps, the outcome (approved, rejected, withdrawn, admin overridden), and the content hash for the version they signed off on. One audit trail per workspace.
It is. The approvals area runs on phones with a list view for what's pending and a detail view for reading a post and deciding. The same approve and reject actions are available on both.
Agency and Scale. The internal approvals area is gated to Agency plan and above. Pricing page has the comparison.
Set expectations for reviewers, timelines, feedback rounds, and final signoff before the work starts.
Plan the monthly set of posts before the real drafts move into approval and scheduling.
Use audit findings to explain why a review batch includes certain channels, pillars, or formats.
Agree on pillars, formats, and campaign logic before reviewers judge individual posts.