Assigned-only agents: when teammates should only see their own tickets

An assigned-only agent is a teammate who can see and act on only the tickets assigned to them — not the rest of the workspace queue. Use it for contractors, outsourced or junior tiers, and privacy-sensitive queues where the default "everyone sees everything" shared inbox is too broad. The one rule that matters: the scope has to be enforced on the server, not just hidden in the interface.

When you need it

A shared inbox is deliberately open by default — agents pick up whatever needs work, and that transparency is the whole point. But some people on the team shouldn't see the whole queue. An assigned-only agent sees only the tickets assigned to them and nothing else in the workspace.

• Contractors and outsourced tiers. A vendor handling overflow or after-hours coverage needs to work their own tickets, not browse every customer conversation you have.
• Junior or onboarding agents. Narrowing the queue keeps new hires focused on their assignments and reduces the blast radius of a mistake while they learn.
• Privacy-sensitive queues. Billing disputes, legal, abuse reports, or anything touching sensitive personal data shouldn't be casually readable by the whole team.
• Partner or reseller staff. In an agency or multi-client setup, a partner's staff should see their slice and nothing belonging to another client.

If none of those apply, you probably don't need it — an open queue with good saved views is simpler. Reach for assigned-only when "who can read this conversation" is a real question, not a convenience.

How it works

Assigned-only is a role within RBAC, not a per-person toggle you flip and forget. You grant the role; the system applies the scope everywhere automatically. That scope follows the assignment relationship — the ticket's assignee field — and is re-evaluated on every request rather than baked in at login.

Concretely, the scope covers every surface where a ticket could surface:

• The ticket list. Only assigned tickets appear; the rest of the queue simply isn't returned.
• Search. Queries run against the same scoped set, so search can never surface someone else's conversation.
• Direct links and the API. Opening a ticket URL or hitting the API for a ticket you aren't assigned to returns a not-found / forbidden response, not the content.
• Reporting and exports. Aggregates and CSV exports respect the same boundary.

Because it keys off the assignee, it composes cleanly with your routing. New work reaches an assigned-only agent through round-robin or a rule that sets the assignee; the instant a ticket is assigned, it appears for them, and the instant it's reassigned away, it disappears.

Assigned-only vs. teams and saved views

These three are easy to conflate, but they answer different questions. The table below is the short version.

A saved view is a convenience: it changes what you see first, but the underlying data is still reachable. A team narrows the queue to a group everyone on that team shares. Assigned-only narrows it to a single individual. You can combine them — for example, an assigned-only agent inside a specific team — but don't reach for a saved view when you actually need a permission boundary.

Why it must be server-enforced

This is the part people get wrong. If visibility is enforced only in the browser — hiding rows, graying out buttons — the data still traveled to the client, and a crafted request, a guessed ticket ID, or the network tab can read what the UI hid. Client-side scoping is a UX nicety, not a security control.

Cherryrise enforces the scope server-side. The filter is applied in the query layer before any data leaves the server, so a request for a ticket outside an agent's scope returns nothing — there's no payload to inspect. This is the same discipline that underpins multi-tenant isolation between workspaces and the rest of our access model; assigned-only is just a tighter boundary applied inside a single workspace. The practical test is simple: an assigned-only agent should not be able to read another agent's ticket even with the browser closed and a script hitting the API directly. If they can, the scope is theater.

Rolling it out without friction

Scoped visibility only works if the right tickets actually reach the scoped agent — otherwise you've built a queue that looks permanently empty. A few practices keep it smooth:

• Automate assignment. Pair the role with a routing rule or round-robin so work lands on the agent automatically. Don't rely on someone manually assigning every ticket.
• Decide who reassigns. An assigned-only agent usually can't hand a ticket to a teammate they can't see. Define an escalation path — a full agent or admin who reassigns on request.
• Keep collaboration visible to those who need it. Internal notes and @mentions should reach the people working the ticket. Read our notes on assignment and collision detection for how that fits together.
• Review the role on offboarding. When a contractor's engagement ends, removing the seat removes their access. Per-seat pricing makes that clean — see pricing.

Pitfalls to avoid

Two failure modes show up repeatedly. The first is over-scoping: locking down so much that agents can't do their jobs and start emailing each other to move tickets around, which defeats the audit trail entirely. Grant the narrowest role that still lets people work. The second is assuming the role is a substitute for tenant isolation — it isn't. Assigned-only narrows visibility within one workspace; keeping separate customers in separate tenants is a different and stronger boundary. If you're hosting your own instance, the same enforcement applies — see self-hosting for how the scope behaves on your infrastructure.

Frequently asked questions

Can an assigned-only agent search the whole workspace?

No. Search runs against the same scoped query as the ticket list, so results only ever include tickets assigned to that agent. There is no separate search index that bypasses the scope, and no global search box that returns other people's conversations.

What happens to a ticket an assigned-only agent reassigns away?

It disappears from their view the moment it is no longer assigned to them. Scoping is evaluated on every request, not cached at login, so reassignment, unassignment, and team changes take effect immediately.

Is assigned-only the same as a private team or group?

No. A team or group narrows the queue to a shared subset that every member of the team can see. Assigned-only narrows it to one person: only the tickets assigned to that individual. You can combine the two, but they answer different questions.

Do assigned-only agents count as full seats in pricing?

Cherryrise charges per agent seat, with no per-resolution or per-ticket fees. An assigned-only agent is a normal seat with a narrower role, so a contractor handling a small queue costs the same as any other agent and nothing extra per ticket they close.