Roles and approvals for a small team
A small team does not need a process. It needs to know who can publish, who must be asked first, and what happens when nobody answers. NioConnect has three roles, three approval modes and one review window.
The NioConnect team5 min readOn this page
Start from zero ceremony
Approvals are off by default. A solo user never sees a review step, and a team only gets one when it turns it on. That default is deliberate: control should be something a team adds, not something every user pays for in clicks.
Whether a workspace can turn approvals on, and how many people can take part, depends on the plan. The pricing page shows what each plan includes.
Three roles
Every member of a workspace has one of three roles: Owner, Admin or Contributor. The Owner is the one role you cannot assign to someone else, so a workspace always has someone who is accountable for it. Admins and Contributors are what you hand out when you invite people.
Roles matter for approvals because the approval mode can be set around them, and because an API key or an AI connection acts with the role of the member who made it.
Three approval modes
The approval setting is workspace wide and has three values. Pick the narrowest one that does the job.
| Mode | Who needs approval | A good fit |
|---|---|---|
| Off | Nobody | A solo user, or a team that trusts each other fully |
| Contributor only | Posts written by Contributors | A team where Contributors draft and others publish |
| All | Every post, whoever wrote it | Client work, or anything that goes out in someone else's name |
What a post goes through
A post that needs approval is saved as a draft with a pending approval, and it stays a draft until a reviewer signs off. It cannot reach the queue before that, which is the point of putting approval inside the pipeline: there is no moment when an unreviewed post is waiting to go out. The explanation of approval before queueing covers why.
A reviewer can approve or reject. The author can withdraw a post they submitted, and it goes back to being an editable draft. A rejected or withdrawn post is never published by accident.
The review window
Review that never ends is its own kind of failure, so a pending approval has a window. The default is seven days, and a workspace can choose a shorter or longer one from a fixed list, from six hours up to thirty days. When the window passes, or the scheduled moment passes first, the approval expires and the post is held rather than published. It does not slip through.
If you schedule days ahead, a long window is fine. If you post same day, pick a short one so an unanswered request does not quietly eat a slot.
Three common setups
Most small teams land on one of three shapes. None of them needs more than a setting and a short conversation.
- One person, no review. Leave approvals off. Nothing changes for you, and nothing is asked of you.
- A writer and a publisher. Choose Contributor only. The writer drafts and submits, a reviewer signs off, and Owners and Admins can still post their own work directly.
- Work done in a client's name. Choose All. Every post waits for a sign off, including the ones an Owner writes, so the rule has no exceptions to explain.
Sending a post back
A rejection is more useful with a reason. Reviewers can leave a note when they send a post back, and the team can discuss a post on the post itself with internal comments, so the conversation stays attached to the thing it is about instead of scattering across chat.
Posts that an AI assistant created are treated the same way. A draft made through an API key or an MCP connection waits for review like any other post when your workspace requires it, which is why connecting an assistant does not mean giving up the approval step.
Inviting people and changing roles
When you invite someone you choose between Admin and Contributor. You can change a role later. The change applies at once, and it reaches further than the person: an API key or an AI connection resolves the role of the member who made it on every call, so demoting or removing that member limits their keys on the very next use.
That is worth remembering when someone leaves. Taking them out of the workspace does not leave a forgotten key with the permissions they used to have.
Who did what
Approvals, rejections, role changes and channel changes are written to an append only audit log that cannot be edited afterwards. That matters most for the question teams ask after something goes wrong: who changed this post, and who signed it off.
Turning it on
The short version, for a small team:
- Invite the people who will write, and give each the role that fits.
- Choose an approval mode in the workspace settings. Start with Contributor only if you are unsure.
- Pick a review window that matches how far ahead you schedule.
- Ask a teammate to submit a test post and approve it, so everyone has seen the flow once.
The step by step version is the guide to turning on approvals for your team, and the teams page shows the feature in the product.
Written by The NioConnect team.
Posts that say why they failed, on one calendar.
Start 7-day trial