Role-based access for support teams (without locking everyone out)

Role-based access control (RBAC) assigns permissions to roles — admin, agent, assigned-only — and then puts people in roles, instead of granting access to each individual by hand. For a support team, three roles cover almost everything, and the cardinal rule is that every role must be enforced on the server, not just hidden in the UI. Get those two things right and you get least-privilege access without grinding work to a halt.

Why roles, not per-person grants

RBAC grants permissions by role instead of fiddling with individuals. The difference matters the moment your team is bigger than a handful of people. Per-person grants drift: someone gets elevated for a one-off task and never gets walked back, a leaver keeps access for weeks, and nobody can answer "who can do what" without reading a spreadsheet.

Roles fix that by making access a property of the job, not the person:

• It scales with churn. New hire joins, gets a role, inherits exactly the right permissions. They leave, you remove the seat — no orphaned grants.
• It's legible during an audit. "Agents can do X, admins can do Y" is a sentence; a pile of individual exceptions is not.
• It's consistent. Two people in the same role have identical access, so behavior is predictable and bugs are reproducible.

The cost of roles is up-front thought about what the roles should be. That's a feature — it forces you to decide your access model deliberately rather than accreting it one exception at a time.

The roles support actually needs

Resist the urge to build a dozen roles on day one. Most support teams need exactly three, and adding more before you have a concrete reason just creates confusion about which one to grant.

The assigned-only role is the one teams overlook and then badly need. Contractors, outsourced overflow, and privacy-sensitive queues all require it — situations where "everyone sees the whole queue" is exactly wrong. It scopes a teammate to their own work and nothing else, and it composes with round-robin assignment so the right tickets actually reach them.

Designing roles without locking people out

The failure mode that gives RBAC a bad name is over-restriction: lock everything down so hard that agents can't do their jobs and start routing around the system — emailing tickets to each other, sharing logins, working off a personal copy. That destroys the audit trail you built roles to protect. A few principles keep the balance:

• Grant the narrowest role that lets the job get done — but make sure it actually lets the job get done.
• Default to agent, escalate to admin sparingly. Admin is for configuration, not for everyday ticket work. Most people never need it.
• Pair scoped roles with automation. An assigned-only agent with no routing has an empty queue; give them work through round-robin or a rule.
• Define escalation paths. A scoped agent often can't reassign to someone they can't see — decide who handles that before it's an emergency.

Enforce server-side

A role that only hides buttons is theater. If the restriction lives in the browser — graying out a control, filtering a list client-side — the underlying data still traveled to the client and can be retrieved with a crafted request, a guessed ID, or the network tab.

Real enforcement happens on the server, on every surface a ticket can appear: the list, search, direct links, the API, exports, and reporting. The query layer applies the role's scope before any data leaves the backend, so a scoped agent literally cannot fetch what they shouldn't — there's nothing to intercept. The honest test: can a restricted user reach forbidden data with the UI bypassed entirely and a script hitting the API? If yes, the role isn't real. The same principle governs AI controls — AI assist is opt-in and admin-gated, and it works within the same boundaries as the agent invoking it, so it can't become a side channel around a role. You can read how we apply this across the product on our security page.

RBAC vs. multi-tenant isolation

These two get conflated, and the distinction is worth keeping crisp. RBAC partitions permissions within a workspace — what an admin versus an agent can do. Multi-tenancy partitions data between workspaces — keeping separate customers' tickets in isolated tenants that can never see each other. Roles are the soft internal lines; tenancy is the hard external wall. An agency serving many clients needs both: tenancy so client data never crosses, and roles so each client's own staff see only their assignments. Don't reach for a role when you actually need a separate tenant, and don't assume separate tenants remove the need for roles inside each one.

Auditing and changing roles

Roles aren't set-and-forget. Build a light review into your operations so access stays current as the team changes:

• Review on join and leave. Granting a role on onboarding and removing the seat on offboarding should be routine. Per-seat pricing with no per-resolution fees makes adding and removing seats clean.
• Re-check elevated access periodically. Admin is the role to watch — confirm the list of admins still matches who needs it.
• Treat role changes as immediate. Because enforcement is evaluated per request, a role change takes effect right away, not at next login. Use that — revoke the moment access should end.

If you run your own instance, the same model applies on your infrastructure; see self-hosting your help desk for how roles and enforcement behave when you control the deployment.

Frequently asked questions

How many roles does a support team actually need?

Most teams are well served by three: admin, agent, and assigned-only. Admins configure the workspace, agents work the whole queue, and assigned-only agents see just their own tickets. Add more only when a real responsibility doesn't fit one of those — extra roles you can't clearly describe become a maintenance burden.

What is the difference between RBAC and multi-tenancy?

RBAC controls what a person can do inside one workspace. Multi-tenancy keeps separate customers' data in isolated workspaces so they can never see each other at all. They solve different problems: roles partition permissions within a tenant, while tenancy is the hard wall between tenants.

Why isn't hiding buttons in the UI enough?

Because the data still reached the browser. Anything hidden in the interface can be retrieved with a crafted request, a guessed ID, or the network tab. A role is only real if it's enforced on the server, where the restricted data never leaves the backend in the first place.

Should AI features respect roles too?

Yes. AI assist in Cherryrise is opt-in and admin-gated, and it operates within the same permission boundaries as the agent using it. A scoped agent's AI suggestions are drawn only from tickets they're allowed to see, so the feature can't become a side channel around the role.