Flip a workspace switch and every member-submitted post lands in an approval queue. Owners and admins approve, reject with a reason, or batch-clear. The post ships on its original schedule the moment it’s green-lit — no schedule rewrite, no client surprises.
Approval status set at the API layer, not the UI. Client tampering can’t bypass the queue.
Owners and admins skip the gate. Only member submissions wait for sign-off.
Required comment on rejection — the member sees exactly why and what to fix.
Multi-select pending posts. One action clears the queue.
Every submit / approve / reject / comment writes to post_approval_events. Visible in Activity Log.
Approval doesn’t rewrite the schedule. Post ships at its original time once green-lit.
Discuss freely on the draft, then submit. The two flows stay distinct on purpose.
Full UI shipped in all 8 supported languages — no English-only chrome.
Workspace settings → Team Approvals → toggle "Require member approval before publish". Owners and admins only.
Members compose and schedule like normal. Aidelly silently puts the post in approval_status = pending — no extra step in the composer.
Open /team-approvals. Approve, reject with a reason, or batch-clear. Filters for platform, account, and date.
Once approved, the post enters the normal publish pipeline at its original scheduled_at — no schedule rewrite.
When the workspace toggle "require member approval" is on, any scheduled post created by a workspace member is held with approval_status = pending. Owners and admins always bypass the gate — their posts publish on schedule. The gate is evaluated server-side at create time so client tampering can’t skip it.
Workspace owners and admins. Members can see their own pending submissions on the Team Approvals page (read-only), but only owners/admins see the approve/reject controls. This matches the existing role model — admins are managed by the owner.
Approve: the post’s approval_status flips to approved and it enters the regular publish pipeline at its original scheduled_at. Reject: the post moves to approval_status = rejected and is returned to draft with the rejection reason attached. The submitting member is notified in-app and (if configured) by email.
Yes. Every approval action — submitted, approved, rejected, returned to draft, commented — writes a row to post_approval_events. Visible on the post detail drawer and in the workspace activity log. Useful for client SLAs and internal incident reviews.
Yes. Multi-select on the Team Approvals page, then "Approve selected" or "Reject selected". A rejection requires a reason — Aidelly will prompt for a single comment that applies to the batch.
Draft Discussions still works for back-and-forth before submission. Approvals are the formal sign-off step — typically the discussion happens first, then the member submits, then the owner approves. Every approval action is also recorded in the Activity Log so the full chain is in one place.
One queue. One sign-off. Every post audited.