Skip to content

Role-Based Access Control(RBAC)

Also called: Role-based permissions · User roles and permissions · Role-based access

Granting permissions to roles such as admin, developer, agent and analyst, then assigning people to roles, instead of setting permissions person by person.

Reviewed

What is role-based access control (RBAC)?

Role-based access control (RBAC) is an access model in which permissions are granted to roles and people are assigned to roles, rather than each person receiving a hand-picked list of permissions. A role describes a job (admin, developer, campaign manager, support agent, analyst) and bundles exactly the actions that job requires. When someone joins, moves team or leaves, you change their role assignment and their access follows. The model was formalised by researchers at the US National Institute of Standards and Technology in the 1990s and standardised as ANSI INCITS 359 in 2004.

In a WhatsApp operation, roles live in two layers. Meta Business Manager, now called the business portfolio, decides who can manage assets: who has full control of the portfolio, who can work on a WhatsApp Business Account's templates and phone numbers, who sees billing, and which System User identities hold API tokens. Your messaging dashboard or Shared Team Inbox decides what people can do with conversations: an agent replies to assigned chats but cannot export contacts, edit templates or launch a broadcast; an analyst sees reports with phone numbers masked; a developer manages webhooks and API keys without reading customer chats.

RBAC is the role model itself, whereas the Principle of Least Privilege is the rule it should follow: each role holds the minimum its job needs, and each person gets the narrowest role that fits. It also differs from attribute-based access control (ABAC), which decides each request from attributes such as team, region or conversation owner; most inboxes combine the two, using roles for what you may do and attributes for which conversations you may do it to. Pair RBAC with Single Sign-On (SSO), so roles come from directory groups, and with an Audit Log, so every role change and sensitive action leaves a record.

Key takeaways

  • Role-based access control (RBAC) attaches permissions to roles and assigns people to roles, so access follows the job rather than the person.
  • Most WhatsApp teams need only four to six roles, such as admin, developer, campaign manager, support agent and analyst.
  • Access has two layers: Meta's business portfolio decides who manages the WABA, and your inbox decides who can read chats or export contacts.
  • Enforce roles on the server for every request; hiding a button in the interface is not access control.
  • RBAC delivers least privilege only if roles stay narrow, so review assignments on every join, move or leave and log each role change.

See InfiQ pricing

Interactive stop

Who can do what? Explore a WhatsApp team's role matrix

5 / 5
Who can do what? Explore a WhatsApp team's role matrix. 5 rows by 5 columns. Each cell is a button: activate it to read its note, and use the arrow keys to move between cells.
Reply to chatsSend broadcastsSubmit templatesExport contactsAPI keys & webhooks
Admin
Developer
Campaign manager
Support agent
Analyst

Hover, tap or arrow-key through the cells — a dot in the corner means there is a note.

Analyst by Reply to chats

Read-onlyRead-only

Sees conversation metrics, not live chats.

Legend — press one to highlight its cells

Five roles against five sensitive actions in an illustrative WhatsApp operation. Focus any cell for the reason behind it, or pick a legend colour to see every action of that kind at once.

Row 5 of 5. Analyst × Reply to chats: Read-only. Sees conversation metrics, not live chats.

How does role-based access control (RBAC) work?

  1. List sensitive actions, not screens

    Write down what matters in your WhatsApp stack: reply to chats, view every conversation, send broadcasts, create or submit templates, export contacts, manage webhooks and API keys, view billing and manage users.

  2. Design a few roles from real jobs

    Group those actions into four to six roles, such as admin, developer, campaign manager, support agent and analyst. When an exception appears, prefer an attribute rule or a narrow new role to widening an existing one.

  3. Mirror the model in Meta's business portfolio

    Keep full control of the portfolio to two or three people, give WABA access only to those who manage templates, numbers or billing, and run integrations through system users rather than personal accounts.

  4. Enforce on the server

    Map every API endpoint to a permission and check the caller's role on each request, then scope queries to the records that role may touch. Return 403 for a missing permission and 404 for records outside the caller's scope.

  5. Assign through groups and review

    Map identity-provider groups to roles at sign-in, review assignments quarterly and on every join, move or leave, and write each role change, with who approved it, to the audit log.

Example: Five roles for a Hyderabad hospital's WhatsApp desk

A multi-speciality hospital in Hyderabad runs appointment reminders, report notifications and patient support on one WhatsApp number, with 40 front-desk agents, a three-person marketing team, two developers and an external analytics agency. Before RBAC, everyone shared four admin logins. The hospital now defines five roles: agents reply only to conversations assigned to their department and see patients' numbers masked to the last four digits; marketing builds broadcasts and drafts templates, but a second person approves each submission; developers manage webhooks and API keys but cannot open chats; the agency gets read-only dashboards with masked numbers; and two IT administrators hold full control of the business portfolio, both using two-factor authentication. When a nurse moves from the front desk to the billing team, one role change moves her access with her.

— Five roles for a Hyderabad hospital's WhatsApp desk

Role-based access control (RBAC): key facts and limits

Standard
ANSI INCITS 359-2004 (NIST RBAC model)
Typical WhatsApp team roles
Admin, developer, campaign manager, agent, analyst
Access layers
Meta business portfolio + your messaging dashboard
Where to enforce
Server-side, on every API request
Missing permission
HTTP 403 Forbidden
Record outside the caller's scope
HTTP 404, so IDs cannot be probed
Review cadence
Quarterly, plus every join, move or leave
Companion model
ABAC: decisions from attributes such as team or owner

Role-based access control (RBAC) in code

// Permissions belong to roles; people only ever get roles.
const ROLES = {
  admin:     ["chat.reply", "chat.view_all", "broadcast.send", "template.submit", "contacts.export", "api.manage", "users.manage"],
  developer: ["api.manage"],
  marketer:  ["broadcast.send", "template.draft"],
  agent:     ["chat.reply"],
  analyst:   ["reports.view"],
};
 
export const can = (user, action) => user.roles.some((r) => ROLES[r]?.includes(action));
 
export const requirePermission = (action) => (req, res, next) =>
  can(req.user, action) ? next() : res.status(403).json({ error: "forbidden", action });
 
// The role says WHAT you may do; the query says WHICH records you may do it to.
app.post("/api/conversations/:id/reply", requirePermission("chat.reply"), async (req, res) => {
  const convo = await db.conversation.findFirst({
    where: {
      id: req.params.id,
      tenantId: req.user.tenantId,
      ...(can(req.user, "chat.view_all") ? {} : { assigneeId: req.user.id }),
    },
  });
  if (!convo) return res.sendStatus(404);  // outside your scope looks like "not found"
  await sendReply(convo, req.body.text);   // the server's token calls the Cloud API
  res.sendStatus(202);
});
 
app.post("/api/contacts/export", requirePermission("contacts.export"), exportContacts);

Check the permission in middleware and the record scope in the query; a forgotten check in either place is broken access control.

Common mistakes with role-based access control (RBAC)

  • Everyone is an admin

    Handing out the admin role to save time turns RBAC into decoration. Keep admins to two or three people, require two-factor authentication for each and review the list at least quarterly.

  • Enforcing only in the interface

    Hiding the Export button while the API still accepts the call from any signed-in user is broken access control. Check the role on the server for every request, including internal tools.

  • Role explosion

    A new role for every exception ends with dozens of roles nobody understands. Keep a handful of job-based roles and use attributes such as team, region or assignee for the exceptions.

  • Shared logins

    A shared support login makes roles meaningless and the audit log useless. Give every person their own account, ideally through SSO, and every integration its own system user.

  • Forgetting the Meta side

    Tight inbox roles help little if 15 people hold full control of the business portfolio. Review Business Manager access alongside your own roles, on the same schedule.

Why does role-based access control (RBAC) matter?

Without roles, access grows one favour at a time: an agent gets admin rights to fix a single template, a seasonal temp keeps export rights after the sale, and nobody can say who is able to download the full contact list. RBAC makes access explainable. One table answers an auditor, an enterprise customer's security questionnaire or a DPDP Act review; 30 festive-season agents can be onboarded in minutes with the same safe role; a leaver loses everything with one change. It also caps the damage from a phished or careless account, because an agent's role simply cannot export data or change the number's settings.

Best practices for role-based access control (RBAC)

  • Start new users with no role and grant the narrowest one that fits.
  • Mask phone numbers by default for roles that do not need them, such as analysts and agencies.
  • Require a second approver for template submissions and contact exports.
  • Name roles after jobs, not people, and publish one table showing what each may do.

RBAC FAQs

What is RBAC, with an example?+
RBAC gives permissions to roles and roles to people. In a WhatsApp inbox, the agent role replies to assigned chats, the marketer role sends broadcasts, and only the admin role can export contacts or manage users.
What is the difference between RBAC and least privilege?+
Least privilege is the principle; RBAC is one way to implement it. RBAC follows least privilege only when every role holds the minimum its job needs and each person is given the narrowest role that fits.
What is the difference between RBAC and ABAC?+
RBAC decides access from a person's role; ABAC decides it from attributes such as team, region or record owner. Many inboxes use roles for which actions a person may take and attributes for which conversations they may see.
Do support agents need access to Meta Business Manager?+
Usually not. Agents work in your inbox, which calls the Cloud API with a system user's token; only people who manage templates, phone numbers, billing or users need business portfolio access, and only a few need full control.
How do I enforce RBAC in my own application?+
Check permissions on the server for every request. Map each endpoint to a permission, verify the caller's role before running it, scope database queries to the records the role may touch, and log denied attempts.

Talk to InfiQ

From definition to your first message

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms