問題被匯報時誰會收到通知
兩封電郵、三則應用程式通知，以及每一種背後確切的收件名單 — 另外還有三個完全不會通知任何人的時刻。
工單管理會送出兩封電郵與三則應用程式通知，而它們的收件名單並不相同。 難處全在這裡：同一件事沿著不同通道抵達不同的人，而支援管理員在其中一條上， 不在另一條上。
一則匯報、兩條名單不同的通道 — 以及兩條都不在的匯報者。
兩封電郵
新問題報告
在工單建立的那一刻寄出，不論來自哪個介面 — 應用程式、會議室面板， 或管理員使用新增報告。
誰會收到，取決於一件事：新工單是否已經有處理人。
- 建立時就已指派 — 只有那個人。
- 未指派 — 所有具備支援管理員讀取權限或列在 支援職員裡的人。
然後，兩種情況都一樣，涵蓋該被匯報資源的 工單政策 會把它的職務持有人疊加上去。
同時符合兩種條件的人 — 既是支援職員又是職務持有人，或在房間與建築物上都持有職務 — 收到的仍然剛好是一封。
已指派支援事件給您
在工單被指派時寄出，只寄給被指派的那個人。重新指派會寄給新的人； 前一位不會被告知自己已經被換掉。
三則應用程式通知
| 通知 | 誰會看到 |
|---|---|
| 新報告問題 | 工單有處理人時是那個人；否則只有支援職員 |
| 已指派支援事件給您 | 被指派的人 |
| 新留言 | 匯報者、處理人，以及所有已經留過言的人，但不含寫這則留言的人 |
「新問題報告」電郵。
應用程式裡的工單通知。
兩條通道不一致的地方
請把上表的這一列和電郵規則並排著讀，因為會引來客訴的就是這一處：
未指派的匯報會寄電郵給支援管理員與支援職員；應用程式通知只送給支援職員。
所以一位有權限、卻從未把自己加進支援職員的管理員，會收到郵件、永遠等不到鈴鐺， 於是斷定通知壞了。把自己加進支援職員就會恢復。同樣的不對稱也表示工單政策的職務持有人 只會收到電郵，永遠不會收到應用程式通知：政策是一條電郵規則，僅此而已。
三件不會通知任何人的事
- 變更狀態。 把工單移到處理中、已處理或已關閉，任何時候都不會送出任何東西給任何人 — 包括匯報它的人。如果有人在等消息，請改用留言。
- 批次變更。 同上，只是數量變多。
- 被匯報這件事本身。 匯報問題的人，在自己的匯報上兩條通道都不在。
匯報者能看到什麼
從應用程式匯報的人，會在已匯報問題篩選裡追蹤自己的工單：即時的狀態與留言串。 這是原本設計的路徑，也是為什麼「沒有電郵」不是一個缺口。
在會議室面板上做的匯報沒有這條路徑。它經常是匿名的，也不繫在匯報者會回來的任何畫面上， 本來就設計成送出即結束 — 請參閱 在面板上匯報。