Control who can send what

A new front-desk hire at an edtech company, three days into the job, accidentally sends a broadcast meant for internal testing to the entire parent contact list — because nothing in the interface stopped a fresh agent-level account from reaching the same send button a supervisor should have approved first.

Role-based access control is what prevents that. An admin assigns each team member a role — agent, supervisor, admin — that determines exactly which actions and conversations they can touch. Sending a broadcast, editing a template, or changing billing settings only becomes available to whichever roles are actually meant to do it, and every one of those consequential actions is logged with who did what and when.

The most direct risk this capability closes is an agent-level account performing an action that should have needed admin approval first — sending a broadcast to the entire contact list is the clearest example, but editing an approved template's wording or changing billing configuration carries similar weight. Left unscoped, any staff member with inbox access could trigger real messaging costs or a policy violation the business never intended, and role-based permissions exist specifically to make that structurally impossible, rather than relying on training alone.

Permission checks have to run on the server for every request, not merely be hidden or greyed out in the interface. A check that only exists in the UI — hiding the broadcast button from an agent-level view, for instance — can be bypassed by anyone calling the underlying action directly, whether through a modified request or a misconfigured integration, and a security model built only on hiding buttons isn't a security model at all. Every consequential endpoint validates the requester's role independently of what the interface happens to show them.

The audit log exists for a specific, concrete reason: if a customer disputes receiving a message they didn't consent to, or a broadcast goes out that shouldn't have, the audit log is the only record of who actually took that action and when. This makes tamper-evidence a real requirement, not a nice-to-have — a log that could plausibly be edited after the fact is worthless as evidence in exactly the dispute it exists to resolve, whether with a customer or Meta over a policy violation.