Granting permissions by role (admin, agent, assigned-only) instead of per person, enforced server-side.
Instead of toggling individual capabilities for each teammate, RBAC defines a few roles, attaches permissions to those roles, and assigns people to them. Adding a new agent means picking a role, not rebuilding a permission set by hand. Because the rules live in one place, what someone can and can’t do stays predictable.
Why it matters
RBAC scales as the team changes and stays legible in an audit — you can answer “who can delete a contact?” by reading the roles, not by inspecting every account. It also reduces over-granting: most people need to handle tickets, not change billing or remove teammates, and roles make that the default. When someone leaves or moves teams, you change their role rather than chasing down a scattered set of individual grants, which keeps access tidy as headcount turns over. See role-based access for support teams.
Common roles
- Admin — full access, including settings, billing, and team management.
- Agent — handles the full queue: replies, assigns, and resolves tickets.
- Assigned-only — sees and works only the tickets routed to them, not the whole inbox. See assigned-only agent.
Common pitfalls
The biggest one is enforcing permissions in the interface only — hiding a button while the underlying API still honors the request. Real RBAC is enforced server-side, so a hidden action is also a blocked action. The other trap is role sprawl: too many near-identical roles defeats the legibility that made RBAC worth adopting. A related mistake is making every new hire an admin “for now” — convenient on day one, but it erodes the boundaries the model exists to keep, and those temporary grants rarely get walked back.
How Cherryrise handles it
Cherryrise ships admin, agent, and assigned-only roles, enforced server-side rather than just in the UI. For example, an e-commerce store can give seasonal contractors an assigned-only role so they handle their routed tickets without browsing every customer’s history. Roles apply within each workspace, alongside multi-tenant isolation; see security for how access is enforced.