Team inbox roles and permissions: who should see what

In a team inbox, give each person the minimum access their job needs: agents read and reply to the conversations assigned to them (and pick up unassigned ones), supervisors see their whole team’s conversations and reports, marketing manages templates and campaigns but not individual support chats, developers manage automations and integrations, and finance sees billing. Only one or two admins can change channels, roles and billing. Build each role from those jobs, test it with a real login, and review it whenever someone joins, moves or leaves.

That is least privilege applied to customer messaging. It’s not about distrust. It protects customers’ personal data, prevents expensive mistakes like a deleted channel or a campaign sent to the wrong list, and makes it obvious who did what.

Why roles matter more in a messaging inbox

A shared inbox concentrates a lot of sensitive material in one place:

• Personal data in plain text. Addresses, phone numbers, ID photos, prescriptions, payment problems. Customers send things on WhatsApp they would never type in a web form.
• Powerful buttons. Disconnecting a WhatsApp number, editing a live flow, sending a bulk campaign or changing an AI model affects every customer at once.
• Credentials. AI provider keys, webhook URLs and functions can move data out of your workspace.
• Money. Workspace balance, invoices and payment links.

When everyone is an admin, a new agent can do all of that on day one. Most incidents in shared inboxes are not attacks; they’re well-meaning people clicking something they didn’t need access to.

Principles for designing roles

Start from jobs, not titles

“Senior agent” and “agent” might do the same work. Ask instead: which conversations does this person need to see, what do they change, and which reports do they need? Two people with different titles and the same answers share a role.

Keep the number of roles small

Four to six roles cover most businesses. Every extra role is something to maintain and audit. If you find yourself creating “Agent – Ayşe”, stop and rethink.

Separate seeing from changing

Many people need to read something without changing it. A supervisor might read the flows to understand why a customer got a message, without being able to edit them. Read-only access is often enough.

Decide conversation visibility deliberately

This is the most important decision for agents. There are three common models:

Model	Agents see	Good for
Open	Every conversation	Small teams that cover for each other, low-sensitivity data
Own plus queue	Conversations assigned to them, plus unassigned ones they can pick up	Most support and sales teams
Own only	Only conversations assigned to them	Clinics, finance, agencies serving several clients, outsourced teams

“Own plus queue” is a good default. Agents can’t browse colleagues’ customers, but nothing gets stuck because unassigned conversations stay visible.

Make admin rare

One or two admins is plenty. Everyone else, including managers, should use a role that matches their job. Admin rights for “just in case” are how roles drift into “everyone can do everything”.

A starting set of roles

Use this as a template and adjust it to your business.

Agent

• Sees: conversations assigned to them, and unassigned conversations they can take.
• Does: reply, add internal notes, transfer or close conversations, update the customer’s profile fields.
• Doesn’t: change channels, flows, AI settings, templates, team members or billing; doesn’t see reports by default.

If you run AI-to-human handoff, agents also need to see conversations the assistant passes to them, which in practice means assigned and unassigned ones.

Supervisor or team lead

• Sees: all conversations of their team, plus reports.
• Does: assign and reassign conversations, close stale ones in bulk, review quality, read flows and AI settings.
• Doesn’t: change billing, connect or remove channels, or manage roles.

Supervisors need reports to run their team. If you track first response time and SLAs, see our guide to chat support metrics for what to put in front of them.

Marketing

• Sees: templates, campaigns and the contact lists they’re allowed to message.
• Does: create and submit templates, prepare and schedule bulk messages, read campaign reports.
• Doesn’t: read individual support conversations, change channels, or edit support flows.

The main risk with marketing access is sending to the wrong audience. Our WhatsApp opt-in guide covers the consent side; permissions cover who can press “send”.

Developer or integrator

• Sees: automations, functions, flows, webhooks, AI models and integration settings.
• Does: build and test flows and functions, connect AI providers and tools, set up webhooks.
• Doesn’t: need access to billing, team management or, ideally, real customer conversations beyond what testing requires.

Treat this role as sensitive even though it’s not “admin”. API keys for AI providers and webhook targets decide where customer data goes. Give it to named people, not to a shared agency login.

Finance

• Sees: billing, invoices, workspace balance and payment records.
• Does: top up balance, download invoices, check payments.
• Doesn’t: read conversations or change anything in the inbox.

Admin or owner

• Everything, including roles, channels and billing. Keep it to one or two people, and make sure at least two exist so nobody is locked out when one is on holiday.

Teams, working hours and roles work together

Roles decide what someone can do. Teams and working hours decide which work reaches them:

• Teams (sales, support, billing, a region or a brand) let you assign conversations to a group and let a supervisor oversee their group.
• Working hours and shifts decide when people are expected to answer, which matters for routing and for honest response-time numbers.
• Statuses such as online, away and offline tell the team who is actually available.

Design the three together. “Agents in the Istanbul team see their own conversations and the Istanbul queue during their shift” is a complete rule; “agents can read conversations” is not.

How to roll out roles without breaking anything

1. List every person and what they do today. A spreadsheet with name, job, channels and the screens they use is enough.
2. Group them into four to six roles using the template above.
3. Create the roles from an existing one, then remove what isn’t needed rather than adding from scratch.
4. Test each role with a real login. Can an agent see the queue? Can a supervisor open reports? Can marketing submit a template but not open support chats?
5. Move people over in small groups, starting with a team that can give quick feedback.
6. Write down the rules in one paragraph per role, so new joiners and auditors understand them.
7. Review regularly: when someone joins, moves or leaves, and every few months for everyone.

When someone leaves, remove their access the same day, and reassign their open conversations so customers aren’t left waiting.

Special cases worth planning for

• Agencies and outsourced teams. Give each external person their own login and an “own only” agent role. When the contract ends, removing access is one step, and their history stays attributed to them.
• Several brands or clients in one workspace. Use teams per brand and keep agents to their own conversations, so one client’s customers are never visible to another client’s agents.
• Temporary and seasonal staff. Create them with the plain agent role, no reports and no access to automations, and put a removal date in your calendar the day you invite them.
• Managers who only want numbers. A read-only role with reports and no access to conversations is often all an executive needs.
• Emergency access. Decide in advance who can grant extra rights at night or at weekends, rather than handing out admin “for now”.

Common mistakes

• Everyone is an admin because it was easier on day one.
• Shared logins for agencies or night shifts. You lose any record of who replied and can’t remove one person’s access.
• Agents who can edit flows and “fix” a message for one customer, changing it for everyone.
• Reports hidden from supervisors, so they manage by feel.
• One giant “custom” role per person that nobody can explain six months later.

How MonoChat does it

In MonoChat, roles live in Settings › Team › Roles. Choose + Create, give the role a name and pick a Reference, an existing role to start from. Then switch each permission on or off.

• Granular permissions by area. Permissions are grouped by area, such as chat (channels, webhooks, sessions and messages), CRM, automation (functions, flows, AI models, MCP, harnesses and agent runs), marketing, reports, team, billing, wallet and payment, with separate read, create, update and delete rights where they apply.
• Own conversations only. Chat sessions have “owned” scopes, such as reading owned chat sessions and reading free (unassigned) ones, so you can limit an agent to their own conversations plus the queue.
• Reports by permission. The Reports menu appears only for roles with the permission to read reports.
• Teams, working hours and shifts are set under Settings › Team, and conversations can be assigned to a person or a whole team, one by one or in bulk from the unified team inbox.

See roles and permissions for an overview, or create a free account at app.monochat.ai and try a role with a test user before you invite the team.