Who gets told when an issue is reported
Two emails, three in-app notifications, and the exact list behind each — plus the three moments that notify nobody at all.
Ticketing sends two emails and three in-app notifications, and they do not share a recipient list. That is the whole difficulty: the same event reaches different people down each channel, and support managers are on one of them and not the other.
One report, two channels with different lists — and a reporter on neither.
The two emails
New issue reported
Sent the moment a ticket is created, from any surface — the app, a room panel, or an administrator using Add issue.
Who receives it depends on one thing, whether the new ticket already has an assignee:
- Assigned as it was created — only that person.
- Not assigned — everyone holding Support manager read access or sitting on Support staff.
Then, in both cases, a ticket policy covering the reported resource adds its role holders on top.
Somebody who qualifies twice over — support staff and a role holder, or a role holder on both the room and its building — still receives exactly one email.
Support ticket assigned to you
Sent when a ticket is assigned, to the person it was assigned to and nobody else. Reassigning sends it to the new person; the previous assignee is not told they have been taken off.
The three in-app notifications
| Notification | Who sees it |
|---|---|
| New issue reported | The assignee if the ticket has one — otherwise support staff only |
| Support ticket assigned to you | The assignee |
| New comment | The reporter, the assignee and everyone who has already commented, except whoever wrote this comment |
The New issue reported email.
Ticket notifications in the app.
Where the two channels disagree
Read this row of the table above beside the email rule, because it is the one gap that produces support calls:
An unassigned report is emailed to support managers and support staff. The in-app notification goes to support staff only.
So a manager who has the permission but never added themselves to Support staff gets the mail and never the bell — and concludes notifications are broken. Adding themselves to Support staff fixes it. The same asymmetry means ticket-policy role holders are emailed and never notified in the app: a policy is an email rule and nothing else.
Three things that notify nobody
- A status change. Moving a ticket to In progress, Resolved or Closed sends nothing, to anyone, ever — including the person who reported it. If somebody is waiting to hear, comment instead.
- A bulk change. The same, in quantity.
- Being reported. The person who reported the issue is on neither channel for their own report.
What the reporter can see instead
Somebody who reported from the app follows their own tickets in the Reported issues widget: the live status, and the comment thread. That is the intended route, and it is why the missing email is not a gap.
A report made at a room panel has no such route. Frequently anonymous and never tied to a screen the reporter will return to, it is send-and-forget by design — see reporting at the panel.