Who can see what: roles in a shared WhatsApp inbox
A new agent does not need your billing page. Setting that up should take two minutes, not a policy document.
Access is granted per section, at one of three levels, and a role is just a saved set of those choices. That is the whole model, and its simplicity is the point — access control that takes an afternoon to understand does not get used.
The sections are the things in your menu: the inbox, automations, broadcasts, contacts, analytics, settings, billing and so on.
The three levels
| Level | Effect |
|---|---|
| Not visible | The section is hidden from the menu and everything in it is blocked |
| Read only | They can look; anything that changes, sends or charges is blocked |
| Read + edit | Full access to that section |
Note that "not visible" genuinely hides the section rather than showing a locked door. That is a better experience for someone whose job does not involve it — a menu with nine items they cannot use is noise.
Admin is a wildcard
The administrator role bypasses the table entirely. Everything is available, including anything added to the product after the role was created.
Which has a practical consequence: a new section is automatically available to admins and automatically hidden from every custom role until somebody grants it. That is deliberate and it is the safe direction — a new page being invisible is a support question, a new page being open to everyone is a problem.
Roles worth creating
Three cover most businesses, and each takes a minute:
- Agent. Read and edit the inbox and contacts. Read-only or hidden for everything else. This is the role most of your team should have.
- Marketing. Broadcasts and analytics, plus read access to automations so they can see what customers are already being told. No settings, no billing.
- Manager. Everything except billing, unless they are the person who pays for it.
Start there, adjust when somebody hits a wall, and resist creating a role per person — five roles is a system, twenty is a filing problem.
Why this matters more on WhatsApp
Because the inbox contains everything. Phone numbers, addresses, order histories and whatever customers volunteered in conversation, all in plain language and all searchable.
That is not an argument for locking the inbox down — your agents need it — but it is an argument for thinking about who else has an account. A seasonal colleague, an agency, a developer: each of them needs some access and none of them needs all of it.
Things worth restricting by default
- Billing, to whoever actually pays.
- Settings, including the WhatsApp connection itself — a disconnection is disruptive and easy to do by accident.
- Broadcasts, because a mistake there reaches thousands of people at once and costs money doing it.
- Publishing automations, which is different from viewing them. Read-only access to automations lets somebody understand the flows without being able to change what customers receive.
That last distinction is the one people find most useful in practice. A new colleague can learn how the flows work on day one without any risk to what is running.
Leavers
The unglamorous half of access control. When somebody leaves, their account should go with them, and so should anything that was theirs alone — an API token, a connected Google account used by a Sheets lookup, a phone number listed in an internal alert.
Worth a short checklist kept with your other offboarding steps. The integration side of it is covered in what you can connect to WhatsApp.
What roles do not change
Nothing about Meta's rules. Templates, opt-in and the 24-hour customer service window in Meta's sending messages documentation apply whoever is typing, and a marketing template still needs approval under Meta's template documentation regardless of who set it up.
Roles govern who can reach a page, not what the platform permits once they are there.
Frequently asked
Can I restrict which conversations someone sees?
Access is granted per section. Within the inbox, assignment is what directs a person to their own work — see assigning chats to the right agent.
How many admins should we have?
At least two, so nobody is locked out, and not many more.
What happens when a new feature is added?
Admins get it immediately; custom roles do not until you grant it. If a colleague says a new page is missing, that is usually why.
Is read-only genuinely safe?
It blocks anything that writes, sends, deletes or charges. It does not hide the data on the page, so use "not visible" where the concern is seeing rather than changing.
Setting up a new colleague in five minutes
- Create their account and assign the Agent role rather than admin.
- Check the menu from their side — if there are items they will never use, set those sections to not visible.
- Give read-only access to automations, so they can understand what customers are being told without being able to change it.
- Add them to the rota so assignment knows when they are working.
- Show them the escalation path for anything they cannot resolve.
Five steps, and the third is the one that most improves how quickly somebody becomes useful. An agent who can read the flows understands why the customer is saying what they are saying.
Read-only is more useful than it sounds
| Section | Read-only lets them | And blocks |
|---|---|---|
| Automations | See every flow and how it branches | Editing or publishing anything |
| Broadcasts | See what has been sent and to whom | Sending, which costs money |
| Analytics | Read the numbers | Nothing much — analytics is mostly reading anyway |
| Settings | See how things are configured | Disconnecting WhatsApp, changing the profile |
The pattern is that read-only is the right level for anything somebody needs to understand but should not operate. That covers most of a new colleague's first month.
Two access questions worth deciding once
Who can publish an automation? This is the change customers feel immediately, and it deserves a smaller group than the one that can view flows. A draft anybody can build and a publish only a few can perform is a good split.
Who can send a broadcast? The one action that reaches thousands of people and charges you for the privilege. Restricting it is not distrust; it is the same reason two people sign a cheque.
Both of those are settings rather than policies, which means they hold even on the day everybody is busy — the argument made at more length in stopping a flow cleanly.
An access review worth doing twice a year
- List every account and who it belongs to.
- Remove anyone who has left, including agencies and contractors.
- Check how many admins you have. More than 3 in a small business usually means the roles were never set up.
- Look at what each role can reach and ask whether it is still right — jobs change more often than roles do.
- Check the credentials nobody owns — API tokens, a connected Google account, phone numbers in internal alerts.
Half an hour, twice a year. The fifth item is the one that catches the quiet failure: an integration that stops working because the person whose account it used has gone.
Why "not visible" beats a warning
Hiding a section is kinder than showing it and blocking it. A colleague who can see billing but cannot open it will eventually ask why, and somebody will spend ten minutes explaining. A menu that only contains what they use needs no explanation.
It also reduces the surface for mistakes. The setting somebody cannot see is the setting they cannot change by accident on a busy Friday.
The short version
3 levels — not visible, read only, read and edit — applied per section, saved as a role. Start with 3 roles: agent, marketing and manager. Keep at least 2 admins and not many more, restrict broadcasts and billing by default, and review who has an account twice a year.
What each role usually needs, in practice
| Section | Agent | Marketing | Manager |
|---|---|---|---|
| Inbox | Read + edit | Read only | Read + edit |
| Contacts | Read + edit | Read + edit | Read + edit |
| Automations | Read only | Read only | Read + edit |
| Broadcasts | Not visible | Read + edit | Read + edit |
| Analytics | Read only | Read + edit | Read + edit |
| Settings | Not visible | Not visible | Read only |
| Billing | Not visible | Not visible | Not visible |
Adjust it to your business rather than copying it, but the shape is a reasonable default: everybody can do their own job, one person can change what customers receive, and the thing that charges your card is reachable by the person who owns it.
The mistake to avoid
Making everyone an admin because setting roles up felt like an afternoon's work. It is closer to 10 minutes for the first role and about 2 for each one after, and the alternative is a business where any account can disconnect WhatsApp.
Where to start if everyone is an admin today
- Create the agent role and move your agents onto it.
- Check nothing they need is missing, by asking them rather than guessing.
- Create the marketing role if anyone sends broadcasts.
- Leave the rest as admin for now.
That single change — agents on an agent role — removes most of the risk in a typical account, and it takes about as long as reading this page.