Agent Ticket Visibility

By default every agent in your workspace can see every ticket in it. If some of your tickets shouldn't be that open — HR cases, payroll queries, anything involving one employee's personal circumstances — you can restrict agents to the groups they belong to.

1. Turning It On

Go to Settings → Groups and switch on Restrict agents to their groups. It saves immediately and applies to every agent from their next page load.

It's off for every workspace until you turn it on, so nothing changes for your team until you decide it should.

Sort out your group membership before you turn this on. Visibility is driven entirely by who is in which group, so an agent who isn't in any group will suddenly find most of the queue missing. The Settings page warns you and names them if that's the case.

2. What an Agent Can See

With the setting on, an agent sees a ticket if any one of these is true:

The ticket	Why they see it
has no group yet	Nothing has decided who owns it, so it needs to be triageable by whoever is looking
is in a group they belong to	Their team's work
is assigned to them	Their work, wherever it came from
was raised by them	They wrote it

Anything else is hidden — not greyed out or partially shown, but absent: it isn't in their queue, their search results, their dashboard counts, or their exports, and opening a direct link to it says the ticket can't be found.

The last two rows are safety valves rather than the point of the feature. Without assigned to them, handing a ticket to a specialist in another team would make it vanish from their own queue the moment they were given it. Without raised by them, an agent who reports a problem to another team would lose their own report — and since they wrote it, hiding it protects nobody.

Admins and owners are never restricted

Anyone with the admin or owner role continues to see every ticket in the workspace, whatever groups they're in. Restricting them would leave nobody able to look across teams, spot a misrouted ticket or answer "where did this get to?".

So if a senior agent needs full visibility, the answer is their role, not their group membership.

Ungrouped tickets stay visible to everyone

A ticket with no assignment group is visible to all agents, on purpose. Most tickets arrive ungrouped and get a group from assignment rules or from an agent reading them. If ungrouped tickets were hidden too, a request that matched no rule would be invisible to the entire team and simply rot in the queue.

The flip side is that this feature only protects tickets that actually reach a group. If you're turning it on to keep sensitive requests inside one team, make sure something routes them there — a sender email rule on the mailbox they arrive at is usually the most reliable way, because it applies before anyone reads the ticket.

3. Agents in No Group

An agent who belongs to no group sees only ungrouped tickets and tickets assigned to or raised by them. They do not see everything.

That's the deliberate choice — the alternative, treating "no group" as "all groups", would mean removing someone from their last group quietly gave them more access than they had before. But it does mean forgetting to put a new agent in a group looks to them like a nearly empty queue, which is why Settings → Groups tells you how many agents are in that state, and who, before and after you turn the setting on.

4. What Isn't Affected

•Employees and the portal. The portal has always shown an employee only their own tickets. This setting is about your agents.

•Assignment and routing. Rules still route tickets to any group, and agents can still assign across groups. Visibility decides what you can read, not where work can go.

•Group filters in the queue. The existing group filter in the queue is still just a convenience filter. With the setting on, it narrows what's already been narrowed.

•QueAssist. The AI copilot answers from the same filtered set, so an agent can't reach a hidden ticket by asking for it.

•Notifications already sent. Turning the setting on doesn't retract email that has already gone out. It changes what's readable in the app from that point on.

5. A Worked Example

A 60-person company runs one service desk with an IT Support group and an HR group. HR requests arrive at hr@company.com; IT requests come through the portal and support@company.com.

1. Put the two HR agents in the HR group, and the four IT agents in IT Support.

2. Add an assignment rule: Sender email hr@company.com → Assign to group HR, and drag it above any catch-all rule so nothing broader claims those tickets first.

3. Switch on Restrict agents to their groups.

From then on a parental-leave query emailed to hr@company.com is routed to HR on arrival and is readable by the two HR agents, the admins and the owner. The four IT agents never see it. The IT queue is unchanged, because nothing routes portal tickets to HR.

Check the rule works before you rely on it — email the address from an outside account and confirm the ticket lands in the HR group. A sensitive ticket that matches no rule stays ungrouped, and ungrouped means visible to every agent.

Next, read Inviting Your Team for how roles work, or Assignment Rules & Groups to set up the routing this depends on.