Team Approvals

Flip a workspace switch and every member-submitted post lands in an owner/admin approval queue, with a reject-with-reason flow and a full audit trail.

What Team Approvals is for

Team Approvals is a server-side gate: when the workspace toggle is on, any scheduled post created by a workspace member is held in approval_status = pending until an owner or admin clears it. If the workspace designates required approvers, posts from owners and admins are held too, and only a designated approver or the owner can clear them. Approved posts ship at their original scheduled time. Rejected posts go back to their author as an editable draft, with the reviewer's reason attached when one was given. A post back in draft never publishes until it is resubmitted and approved.

Useful for agencies who can't let a client misfire, brands with a regulated voice, and any team where the person hitting publish isn't the person signing off.

Where it lives

Workspace setting — Workspace Settings → Team Approvals → "Require member approval before publish". Owners and admins only.
Approval queue — /w/[workspace]/team-approvals (or the matching workspace-scoped path your sidebar surfaces).

Plan availability

Plan	Team Approvals
Launch	Not included
Scale	Included
Agency	Included

The gate is workspace-scoped, so an Agency workspace can have the toggle on for one client and off for another.

How the gate decides

When a scheduled post is created via any surface (composer, calendar, chat, API, MCP), Aidelly evaluates the approval gate server-side:

Who is held depends on which settings are on. "Require member approval before publish" turns the team gate on. Owner review and client review apply on their own, even when the member toggle is off.

Workspace settings	Owner	Admin	Member
Member approval off (no owner or client review)	Publishes on schedule	Publishes on schedule	Publishes on schedule
Member approval on, no designated approvers	Bypasses the gate	Bypasses the gate	Held for approval
Member approval on, with designated approvers	Held, unless a designated approver	Held, unless a designated approver	Held, unless a designated approver
Require owner review on (with the above)	Held	Follows the rows above	Follows the rows above
Require client review on	Held for client review	Held for client review	Held for client review

Notes:

Designated approvers apply to everyone. Once you name specific approvers, all new content is held, including posts created by owners and admins. The only exception is a creator who is themselves a designated approver; their own posts are not held.
Owners and admins bypass only the plain member gate. That is the case where member approval is on and no approvers are designated.
Require owner review holds posts submitted by the workspace owner even when the member gate would let them through.
Require client review holds every submission, including owners and admins, until the client signs off. When a team gate also applies, the post goes through the team stage first.
If Aidelly cannot read the workspace's approval settings, it holds the post rather than letting it publish.

There is no client-side bypass. The decision is made in evaluateApprovalGate() at the API layer, before the post is enqueued.

Step 1 — Turn the gate on

As the workspace owner or admin, open Workspace Settings → Team Approvals.
Toggle "Require member approval before publish" to on.
Save.

From this moment, every member submission lands in the approval queue.

Step 2 — Members submit as usual

Members compose and schedule like normal. There is no extra step in the composer — Aidelly silently sets approval_status = pending on the scheduled post. The post is visible to the submitting member as "Pending approval" on the calendar.

Step 3 — Owner / admin reviews

Open the Team Approvals page.
The queue shows every pending post: caption preview, platform, account, submitting member, scheduled time, and a strip of media thumbnails when the post has images or video.
For each post you can:
- Approve — flips approval_status to approved. Post enters the regular publish pipeline at its original scheduled_at.
- Reject — opens a comment box; the reason is optional. The post goes back to its author as a draft: it keeps its scheduled time on the calendar but won't publish. Submitting member is notified in-app.
- Open detail — click the caption, the media strip, or the 💬 icon on the row. A right-side panel opens with the full caption, every media item, scheduled time, campaign (if any), and a threaded discussion below. Use the discussion to ask the author a question before approving — they get notified the same way Draft Discussions work.

Members of the workspace who aren't approvers can still open the detail panel to read the discussion on their own submissions. Approve / Reject appear only for people who can clear the post: owners and admins when no approvers are designated, otherwise the designated approvers and the owner.

Saved mentions are filled in at publish

Saved mentions and mention aliases are not part of what you approve. Aidelly fills them in when the post publishes, using the saved mentions as they are at that moment. The review preview shows the caption the way it would publish today, with those tags listed under Filled in at publish.

That means editing or deleting a saved mention changes every scheduled post that uses it, including posts that are already approved, and it does not send them back for review. If a tag has to stay fixed for a post, type the final text into the caption instead of relying on a saved mention.

Step 4 — Bulk-clear the queue

For a backlog, multi-select pending posts and:

Approve selected — applies to every selected post.
Reject selected — prompts for a single comment that applies to the whole batch.

Step 5 — Resubmit a post that came back

A rejected post, or one a reviewer or client asked to change, stays on the calendar as a draft with the reason attached. Its author (or an owner/admin) edits it and resubmits it; it goes back into the approval queue at the stage a new submission would, and reviewers are notified again. If its scheduled time passed in the meantime, update the time before resubmitting.

Posts rejected before October 2026 were also canceled; those stay canceled and can't be resubmitted. Duplicate them instead.

Audit trail

Every approval action writes a row to post_approval_events:

Event type	Triggered when
`submitted`	Member submits or resubmits a post
`approved`	Owner/admin approves the post
`rejected`	A reviewer rejects (reason optional)
`returned_to_draft`	A reviewer or client asks for changes
`commented`	Comment added to the approval timeline

Events are visible on the post detail drawer ("Approval timeline" tab) and roll up to the Activity Log.

How Team Approvals interacts with other Aidelly features

Draft Discussions — discuss the draft before submitting it for approval. Discussion is informal; approval is the formal sign-off.
Activity Log — every approval action shows up in the audit trail.
Version History — if a post is rejected, restore an earlier version before resubmitting.
Destination Presets — when a preset fans a member's draft out to multiple channels, the fanned-out posts inherit the source's approval state.
Calendar — pending posts show a "needs approval" badge on the calendar.
Saved mentions — resolved at publish, not at approval. Editing one updates scheduled posts, approved ones included, without a new review (see Saved mentions are filled in at publish).

Client approval portal (white-label review)

If you're an agency managing client workspaces, you can also send posts to your clients for review and approval before they go live — without them needing a login or account.

How it works:

Create a magic-link review token for a client workspace.
Send the client a shareable URL (/review/[token]).
The client taps Approve or Request changes directly on the link (no login).
If approved, the post publishes on schedule. If changes are requested, the post returns to draft for you to edit.
The approval journey is white-labeled (no Aidelly branding) and fully tracked in the audit trail.

This is separate from team approvals — use it to add an extra gate before your internal approvers sign off, or skip team approvals altogether and let clients be the sole reviewers.

See Client Approval Portal for full setup and workflow.

Troubleshooting

My post bypassed the gate — check the table in How the gate decides. Owners and admins bypass only when member approval is on and no approvers are designated. If the workspace names required approvers, every creator is held unless they are one of the approvers.
The toggle is greyed out — only owners and admins can change approval settings, and only the workspace owner can turn on owner self-review. Members can't change them.
Approved post didn't publish — check the Activity Log for a publish failure event. The approval was honored; the failure is downstream.

Related guides

Draft Discussions — the informal review step
Activity Log — full audit trail across the workspace
Version History — restore an earlier draft after rejection
Workspace Settings — where the gate toggle lives