Group assignees and admin-only notes for a support queue
A support queue rarely belongs to one person. This walkthrough sets up a work item that a whole team can pick up, keeps a note the customer should never see, and puts the result on a board your team already triages from.
1. Assign a ticket to a group, not just a person
Open a work item's assignee field and you can pick a person or a group — support tiers, an on-call rotation, whichever group your admin has already set up. Everyone in that group can see and act on the ticket; nobody has to be added one at a time as the roster changes. A work item can carry more than one assignee at once, mixing people and groups freely — a ticket can belong to "Support · L1" and a specific engineer at the same time.
2. Who can actually see the ticket
Assigning a ticket to a group is also how you control who can find it. Work items are private by default:
| Who | Sees the ticket? |
|---|---|
| An assignee (a person, directly) | Yes |
| A member of an assigned group | Yes |
| The reporter | Yes |
| A tenant administrator | Yes — every ticket, always |
| Anyone else | No — the ticket doesn't exist for them |
"No" here means a genuine 404, not a greyed-out row. Someone outside the assignees, the reporter and your admins can't tell the ticket exists by guessing its link.
3. Add a note only administrators can see
Inside the same conversation as the ticket, an administrator can mark a note Internal. It stays in the thread — nothing is duplicated into a separate system — but the reporter and any non-admin assignee never see it, even scrolling back through the full history.
An internal note is a permanent part of the record, not a scratch pad — it's stored, audited and readable by every current and future administrator. Don't put anything in it you wouldn't want read back later.
Being able to see a ticket also means being able to edit it, and to delete it: there is no read-only access to a work item, and a project's roles don't change who sees its tickets. Assign groups accordingly.
4. Put the queue on a board
A kanban board is a view over the same work items — columns by status, drag a card to move it. Putting a ticket on a board doesn't change who can see it: the visibility rules above still decide that. A board just gives a group a shared, at-a-glance way to triage what's already assigned to them.
What's next
Once a queue is set up, most teams also add custom statuses that match their own process, and a workflow that notifies the group when a ticket lands on it — both covered in the next guides.