Approval before queueing, explained

The usual order, and its problem

In many tools a post is scheduled first and reviewed second, usually by someone watching a calendar. The review is a habit, not a rule. It works until the person who would have caught the mistake is busy, and then the post goes out because it was already in the queue.

The order matters because of what sits in the queue. A queue is a promise: this will be published at this time. If review happens after that promise is made, review is a race against the clock, and the clock does not wait for anyone.

Review as a gate in front of the queue

In NioConnect a post that needs review is saved with a pending approval and is never placed in the queue while it is pending. Queued means one thing only: cleared to publish. That makes the rule structural. No query for due posts can find an unreviewed one, because an unreviewed post is not in the set it searches.

The same gate applies to every way a post can arrive: the composer, a change made on the calendar, or an assistant connected through an API key or an AI client. There is one path into the queue, so there is one rule about it.

Recovery cannot skip review

The strongest test of a gate is what happens when something else tries to push work through. NioConnect has an automatic recovery sweep that re-arms stuck posts, and it is exactly the kind of component that could release a held post by accident if approval were only a screen in the app.

It cannot, because approval is one condition in the single admission check that every publish path passes: the sweep, the publishing worker and the scheduler all ask the same question first. Emergency stop, payment standing, allowance, approval and channel health are all answered in one place, so there is no side door that honours some of them and ignores the rest.

Communities get a default hold

Some destinations carry a risk that has nothing to do with your team. Posting automatically into someone else's community can get an account banned. For that reason a post aimed at a Discord channel or a Reddit subreddit waits for approval by default, even when your workspace has approvals switched off.

You can override this for a target, but only by ticking an explicit acknowledgment that automated posting is permitted there and that you accept the responsibility. It is a light safety check, not a team workflow, and it applies on every plan. Reddit itself is still listed as coming soon, but the rule is part of the product now so it is in place before the platform arrives.

What a reviewer can do, and what happens if nobody does

A reviewer sees each pending post rendered for every channel, can edit it in place, and then approves or rejects it. Approving releases it to its scheduled time, or sends it at once if that time has already passed. Rejecting sends it back to draft with a note, and it does not publish.

Review that never ends is its own failure, so a pending approval has a window. The default is seven days and a workspace can change it. A post still pending when the window closes expires and is held, clearly labelled, rather than publishing stale. Social content is time sensitive, and a post that lost its moment should not appear days later because nobody said no.

Why not review after queueing, and cancel if needed

It is a fair question. A post in the queue can be cancelled, so why not let everything queue and rely on a reviewer to pull the bad ones? Because that design makes safety depend on speed. The reviewer has to notice, open the post and act before the scheduled minute, on a day when they may be travelling, asleep or in another time zone.

A gate reverses the default. If nobody acts, nothing is published, and the failure is a post that waited, which is visible and recoverable. In the other design, if nobody acts, the post goes out. For a team that publishes in a client's name, only the first of those is acceptable, and it is cheaper to build once than to keep apologising for the second.

It also keeps the calendar honest. Pending posts show as pending, not as scheduled, so nobody reads a slot as settled when it is still waiting on a decision.

What stays simple for solo users

Approval is off by default. A solo user never meets a review step, and a team only gets one by turning it on. The team approval workflow is part of the plans that include it and is not on Starter, so the pricing page is the place to check what your plan covers.

For the people side of this, three roles, three modes and the review window, read roles and approvals for a small team. The step by step setup is in turn on approvals for your team.

The audit trail

Approvals and rejections record who decided, when, and with what note. They sit in an append only audit log beside channel connections and disconnections, post deletions, role changes and emergency stops. Appending only means an entry cannot be edited afterwards, so a question like who signed this off has an answer that stays the same next month.