Global Notification Bell for Ticket Updates

[dschipfel]

Hello FreeITSM Team,

I would like to suggest a feature that would greatly improve usability and communication within FreeITSM: a global notification system with a notification bell.

Current Situation

At the moment, users need to actively check their assigned tickets to see whether something has changed. This can lead to delays, especially when working in multiple modules throughout the day.

Proposed Enhancement

Introduce a notification bell in the application's header that displays new and unread notifications, such as:

• New tickets assigned to the user
• New comments or replies in assigned tickets
• Status changes
• Priority changes
• Mentions of the user
• Other relevant activities across the system

Why This Is Important

The notification system should be module-independent and available throughout the entire platform. This would allow users to immediately see when action is required, regardless of which module they are currently working in.

Benefits

• Faster response times
• Improved visibility of important updates
• Reduced risk of overlooking ticket changes
• Better user experience
• Increased efficiency for service desk agents and administrators

Possible Enhancements

• Mark notifications as read/unread
• Filter notifications by type
• Optional browser notifications
• Direct link from the notification to the affected ticket or object

I believe such a feature would significantly improve day-to-day work, as users would no longer need to manually check their tickets for changes and could instead react immediately to important updates.

Thank you for considering this suggestion. I would be interested to know whether such a notification system is already planned or if there are existing solutions or plugins available.

Best regards, Daniel

[edmozley]

Hi Daniel @dschipfel, thanks for this, it was a genuinely good suggestion and it is now built and on main.

There is a bell in the header on every screen. It shows what has happened on the tickets assigned to you, with a count of what you have not read, and clicking one opens the ticket. Four of the six things on your list already existed as internal events, so the bell subscribes to those rather than being bolted on to each module separately. The two that did not exist, a note being added and a requester replying, are now proper events, which also means workflows can act on them for the first time.

The design question turned out not to be the plumbing but the volume. An analyst carrying forty tickets would fill the bell faster than they could read it, and a bell everybody ignores has failed even though it still technically works. So four rules apply to everything:

• You are never notified about your own actions. You changed the status, so you do not need telling the status changed. This removes more noise than the other three together, since analysts make most of the changes on their own tickets. System generated events such as an SLA breach still reach you, because nobody performed those.
• Bulk changes produce nothing. Changing fifty tickets at once gives the owner no notifications rather than fifty. Workflows and the audit trail are unaffected, only the bell is quiet.
• Several changes to one ticket become one entry showing a count, rather than one entry each.
• Only types worth interrupting someone for are on to begin with. Assignments, replies, notes, status and priority changes, and SLA warnings are on. New tickets are off, because that is what the inbox is for.

On your enhancements list: mark as read and mark all as read are in, direct links to the affected ticket are in, and filtering is in as per user switches under Preferences rather than a filter on the panel, so you can simply turn off whatever you do not want. Optional browser notifications are not in yet. They need HTTPS to work at all, and plenty of installations run on plain HTTP, so the in app bell had to work properly on its own first.

Two deliberate limits worth stating. Notifications go to the analyst a ticket is assigned to and nobody else, so a ticket you worked on all week goes quiet if it is reassigned. A watch button would fix that later without changing anything already built. And War Room mentions still light up their own icon next to the bell rather than feeding into it, which is the natural next step.

Documentation:

Notifications
Notifications, developer guide

Thanks again for the suggestion, and for setting it out so clearly.

[dschipfel]

We've tested the notification bell so far, and it appears to be working as expected. It's definitely a useful addition and improves the visibility of ticket updates.

One question: would it be possible to add an optional notification sound so users are actively alerted when a new notification arrives?

At the moment, the notification only seems to appear after refreshing the page. Is there already an automatic background check for new notifications, or could real-time notifications be implemented so users are informed immediately without having to reload the page?

We believe this would make the feature even more useful, especially for teams that work in FreeITSM throughout the day.

Thanks again for the implementation and the continuous improvements!