Agent Ticket Visibility

Agents can be restricted to seeing only the tickets belonging to the groups they're a member of — for HR cases, payroll queries, or anything involving one employee's personal circumstances that shouldn't be open to the whole service desk.

Workspaces created from 9 September 2026 have this on already. Older workspaces have it off and are unchanged; you can turn it on whenever you're ready, and section 1 covers what to do first.

1. Turning It On

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

If your workspace was created before 9 September 2026 it's off until you turn it on, so nothing changes for your team until you decide it should.

New agents in a restricted workspace

While the setting is on, an agent you invite from then on is added to your catch-all group automatically when they accept, so they arrive to a working queue rather than an empty one. Move them to the right teams from Settings → Groups — the automatic membership is a starting point, not a decision about where they belong.

This only happens while the setting is on, and only for the catch-all group. Agents are never added to a department group for you.

2. What an Agent Can See

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

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 at all is visible to all agents, on purpose: if ungrouped tickets were hidden too, a request nothing claimed would be invisible to the entire team and would simply rot in the queue.

In practice this is now a rare case rather than the common one. A ticket normally arrives with a group already — from an assignment rule, a department mailbox, a department card on the portal, or failing all of those your catch-all group, which is where anything unrouted lands.

That's worth knowing when you're relying on this feature: a sensitive request that matches no rule isn't left visible to everyone, but it isn't protected either — it goes to your catch-all group, which is usually IT, and is readable by whoever is in it. So still route it deliberately. A sender email rule on the address it arrives at is 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.

It does mean an agent in no group has very little to look at, and since most tickets now arrive with a group that can be an empty queue rather than a thin one. Two things guard against it: an agent invited while the setting is on joins your catch-all group automatically, and Settings → Groups tells you how many agents are in no group, and who, before and after you turn the setting on. Anyone already in the workspace stays exactly where they are, so if you're switching this on by hand, group your existing agents first.

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. Under Settings → Email → Notifications, choose Follow group visibility if new-ticket alerts should follow this boundary too.

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.

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