# Posting Queue, Approvals and Team Roles Are Live: What We Shipped and What We Left Out > Three features shipped this week: a posting queue, a post approval workflow, and Owner, Admin and Member roles. Here is exactly what each one does, and the things we deliberately did not build. **Source:** https://posteverywhere.ai/blog/posting-queue-approvals-team-roles-launch **Author:** Jamie Partridge **Published:** 2026-08-28 --- **Three features went live this week: a [posting queue](/posting-queue), a [post approval workflow](/post-approval-workflow), and [team roles](/team-roles-and-permissions) with Owner, Admin and Member.** The queue lets you set your posting times once and then stop choosing dates. Approvals let a reviewer sign off before anything publishes. Roles decide who can touch account connections, billing and API keys. *Last updated: August 2026.* Product launch posts usually oversell. This one tries to be useful by doing the opposite: for each feature I have written down what it does, and then what it does not do, because the second list is the one that decides whether a tool fits how you actually work. *Written by Jamie Partridge, Founder of PostEverywhere.* ## What shipped Three things, all available now on every plan: 1. **A posting queue.** Set recurring weekly openings once. Add a post to the queue and it takes the next free opening. 2. **A post approval workflow.** A per-workspace toggle. When it is on, members submit posts for approval instead of publishing them. 3. **Team roles and permissions.** Three roles, Owner, Admin and Member, with a visible capability matrix. They shipped together because they solve one problem between them: what happens when more than one person is responsible for an account. ## The posting queue: choose your times once The hardest part of social media is not writing any single post. It is the fiftieth one. Teams start well, publish daily for three weeks, then go quiet, and the reason is rarely a lack of ideas. It is that every post carries a small decision about when to publish it, and small decisions repeated fifty times are what burn people out. The queue removes that decision. You set the openings you want each week, for example weekdays at 09:00. Those openings repeat. When you write a post, you add it to the queue and it takes the next free opening automatically. A few details that matter more than they sound: **Openings are wall-clock times in your workspace timezone.** If you set 09:00, the post publishes at 09:00 where your team works. You are not converting anything to UTC in your head, and you are not discovering in March that everything moved by an hour. **There is a live preview.** Before you commit to a pattern, the queue shows the exact date and time the next ten queued posts will publish. You are looking at the real schedule, not a description of it. **Editing your openings never moves posts already in the queue.** This is the one I would want to know about as a user. In a lot of tools, changing a posting schedule silently reshuffles everything you already lined up, and you find out afterwards. Here, posts that are already queued keep the time they were given. Your new openings apply to what you add next. **The composer has a one-click option.** Write the post, choose "Next queue opening", done. It works across every account you have connected, so a single queued post can go to [Instagram](/instagram-scheduler), [LinkedIn](/linkedin-scheduler), TikTok or any mix of them through [one upload formatted per network](/cross-posting). ### What the queue does not do It does not work out the best time to post for your audience. The queue ships with three starter schedules, called Steady weekdays, Commute and lunch, and Always on. They are labelled inside the product as general guidance rather than times measured from your own followers, and I want the same label on this page. PostEverywhere does not analyse your audience to choose your posting times. There is no model picking slots for you. I am spelling that out because "optimal posting times" is one of the most oversold claims in this category. Plenty of tools imply a personalised recommendation and deliver an industry average. If you want to set your openings from evidence rather than a default, our [research on the best time to post](/best-time-to-post) collects what the platform studies actually show, and [Sprout Social's statistics roundup](https://sproutsocial.com/insights/social-media-statistics/) is a reasonable second source. Set your openings from that, then let the queue handle the repetition. > **Want to try the queue?** Set your weekly openings, add three posts, and look at the preview before anything publishes. Every plan includes a [7-day trial](/pricing). Card required, cancel any time. ## Post approvals: one toggle, one decision Some teams can publish straight to the account and nothing bad ever happens. Others cannot. Agencies posting on behalf of a client, regulated firms, and any brand where a junior team member holds the login all share a problem: the cost of one wrong post is far higher than the cost of a thirty second review. Approvals are a single per-workspace setting called Require approval, and it is **off by default**. Nothing about how your team publishes changes until someone turns it on. When it is on: - **Members submit rather than publish.** The publish button becomes a submit button. - **Owners and admins review.** Everything waiting sits in one inbox, showing the post as it will actually appear, including the media and the target accounts. - **You approve, or send it back with a note.** A note is **required** when you request changes. You cannot bounce a post back in silence, so the author always knows what to fix. - **Authors get email updates.** Approved or sent back, they hear about it without watching a queue. - **Owners and admins always publish directly.** Turning approvals on never blocks the person running the account. ### One approval authorises one publish This is the part I would check in any approval tool before trusting it. The classic failure is the approved post that quietly becomes a different post. Someone gets sign-off on a draft, edits it afterwards, and publishes something the reviewer never saw. If your approval process is really a checkbox, that gap is wide open. Here, an approval authorises exactly one publish, tied to the version that was approved. Change the content after sign-off and it goes back for review. That is the difference between an approval workflow and an approval theatre, and it matters most in exactly the industries that need approvals in the first place. If you are working under advertising or endorsement rules, the [FTC's endorsement guidance](https://www.ftc.gov/business-guidance/resources/ftcs-endorsement-guides-what-people-are-asking) is a useful reminder of why "who approved this" is a question worth being able to answer. ### What we did not build **Multi-step approval chains.** Approvals here are single-approver. One owner or admin signs off. If your compliance process genuinely requires three named people to approve in sequence, we do not do that, and tools like Planable and Sendible do. I have written about where they beat us in our roundup of [social media approval workflow tools](/blog/best-social-media-approval-workflow-tools). **Inline comment threads.** You get a required note when requesting changes, not a threaded discussion attached to the post. **Guest reviewer links.** There is no way to send a client a link to approve without an account. Reviewers are members of the workspace. If any of those three are dealbreakers, that is genuinely useful to know before you start a trial rather than after. ## Team roles: Owner, Admin and Member Most permission systems fail in one of two ways. Either everybody ends up an admin because it is easier, or the rules are so fine-grained that nobody can predict what will happen when they click something. We went with three roles and a matrix you can actually read. ### The capability matrix | Capability | Owner | Admin | Member | |---|---|---|---| | Create and schedule their own posts | Yes | Yes | Yes | | Edit and delete their own posts | Yes | Yes | Yes | | Edit and delete other people's posts | Yes | Yes | No | | Approve posts when approvals are on | Yes | Yes | No | | Connect and disconnect social accounts | Yes | Yes | No | | Invite and remove team members | Yes | Yes | No | | Create and revoke API keys | Yes | Yes | No | | Billing, plan and payment method | Yes | No | No | **Admin is Owner minus billing.** That is the only difference between the two, which makes the role easy to hand out: the person who runs the accounts day to day can do everything except see the card. The restrictions on Member are the interesting ones. A member cannot connect or disconnect a social account, which stops a departing contractor from unhooking a profile the rest of the team depends on. A member cannot create [API keys](/social-media-api), which keeps programmatic access with the people accountable for it. This is ordinary least privilege, the principle [NIST defines](https://csrc.nist.gov/glossary/term/least_privilege) as giving each user only the access their job requires, and which [OWASP treats](https://owasp.org/www-community/Access_Control) as the baseline for access control rather than an advanced feature. ### Why there is no read-only Viewer role We considered one and left it out. A read-only role sounds harmless, but in practice it is the role people get parked in and then quietly work around, usually by asking someone else to publish for them. That is worse than giving them a real role with real limits. If you want someone to see the plan without being able to change it, the honest answer today is that we do not have that, and the [content calendar](/social-media-calendar) plus a screenshot is what people actually do. If enough teams need a genuine viewer role, it is a reasonable thing to build later. ### Seats by plan A seat is a person in your workspace, whatever role they hold. | Plan | Price | Seats | |---|---|---| | Lite | $9/mo | 1 | | Starter | $19/mo | 2 | | Growth | $29/mo | 3 | | Scale | $39/mo | 5 | Approvals need at least two people to be meaningful, so they start being useful from Starter upward. Lite is a single seat and suits one person scheduling their own content. Full details sit on our [plan comparison](/pricing). > **Running more than one brand or client?** [Team workspaces](/team-workspaces) keep each one separate, with its own accounts, its own queue and its own approval setting. Turn approvals on for the client who insists and leave them off everywhere else. ## Why these three shipped together Separately they are three small features. Together they are one workflow. A member writes a post and adds it to the queue. Because approvals are on for that workspace, it goes to an admin instead of publishing. The admin approves it, and it takes the next free opening at the time the team agreed weeks ago. Nobody picked a date, nobody had to remember the posting schedule, and nobody published to a client account without a second pair of eyes. That is the whole point. The scheduling part of social media is not hard, it is just relentless, and most of the friction comes from decisions that should have been made once. This is also why they work with the rest of the product rather than beside it. Queued posts appear on the [content calendar](/social-media-calendar) like anything else. [Uploading a campaign from a CSV](/bulk-scheduling) still handles the campaign uploads that do need specific dates. [Running every profile from one dashboard](/multi-account-management) is unchanged. The publishing itself still runs through the official platform APIs, including the [TikTok Content Posting API](https://developers.tiktok.com/doc/content-posting-api-get-started), the [LinkedIn Posts API](https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/posts-api), the [X API](https://developer.x.com/en/docs/x-api/tweets/manage-tweets/introduction), the [YouTube Data API](https://developers.google.com/youtube/v3/docs/videos/insert), the [Pinterest API](https://developers.pinterest.com/docs/api/v5/pins-create/) and the [Telegram Bot API](https://core.telegram.org/bots/api). ## What this does not change Nothing about your existing setup. Approvals are off by default, so if you are a team of one, today looks exactly like yesterday. The queue is an option rather than a replacement: you can still pick an exact date and time for any post, and for a launch or an embargo you should. The platform list is unchanged at eleven: Instagram, TikTok, YouTube, X, Facebook, LinkedIn, Threads, Pinterest, [Bluesky](/bluesky-scheduler), [Telegram](/telegram-scheduler) and Discord. If you are curious about the newer ones, the [Bluesky documentation](https://docs.bsky.app/docs/get-started) is a good starting point for how that network differs. ## FAQs: the posting queue, approvals and team roles ### Do I have to use the posting queue? No. It is an option alongside exact scheduling. Pick a specific date and time for any post as you always could, and use the queue for the routine content that just needs to go out regularly. ### Does the queue choose the best time to post for my audience? No. It publishes at the times you set. The three starter schedules are general guidance, not times measured from your followers, and PostEverywhere does not analyse your audience to pick slots. ### What happens to queued posts if I change my posting times? They keep the time they were given. Editing your openings only affects posts you add after the change. ### Is approval required by default? No. The Require approval toggle is off on every workspace until an owner or admin turns it on. ### Can a reviewer reject a post without saying why? No. A note is required when requesting changes, and the author receives it with the post. ### Can someone edit a post after it has been approved? They can edit it, but the approval does not carry over. One approval authorises one publish, so a changed post goes back for review. ### What is the difference between an Owner and an Admin? Billing. An admin can do everything an owner can except see the plan, the payment method and invoices. ### Can a member connect a new social account? No. Connecting and disconnecting accounts is restricted to owners and admins, along with team management and API keys. ### How many people can I add? Lite includes 1 seat, Starter 2, Growth 3 and Scale 5. ### Do these features cost extra? No. All three are included on every plan, and every plan has a 7-day trial with a card required. If you want the detail rather than the summary, each feature has its own page: the [queue and how openings work](/posting-queue), [how approvals are reviewed](/post-approval-workflow), and [what each role can do](/team-roles-and-permissions). > **Ready to set this up?** Start a [7-day trial](/pricing) on any plan, set your weekly openings, and invite the person who should be approving. Card required, cancel any time.