Dashboard Change History
Summary: Garrett Wolfe discusses implementing a change notification system within the Sisense environment to keep users informed about dashboard updates without overwhelming them with release notes. The system uses Sisense's API to track changes and individual user acknowledgments, avoiding third-party overhead. Mia Isaacson expresses interest, explaining their potential event-driven approach to similar issues and distinguishes between user awareness of visual changes and deeper interaction analytics.
We don't have a good mechanism to let our users know when we have made an enhancement to a dashboard. We make many little changes and don't want to flood the release notes of our app. We have also tried tools like Pendo, but that comes with too much overhead. What I am working on now is a change history built into our Sisense environment. This gives users a familiar notification symbol when we publish something new, with an unread count so they can see at a glance how much they've missed, similar to a notification bell in any other app they already use. We can set the notification at a global level for updates like "we changed a folder name" or at the dashboard level like "we added a new filter."
The notification also lives right where the change happened, on that dashboard's toolbar, instead of a separate changelog page people have to remember to check so small changes get seen by the people actually using that dashboard. The user can then acknowledge a single change, or clear everything at once, and the notification goes away.
We use Sisense's built-in data storage API to keep the change notes themselves, plus a separate read-status record for every individual user so each person can acknowledge updates independently, without affecting what anyone else sees. It's all native to Sisense too, not a bolted-on third-party service or database, which is exactly what kept this lightweight compared to the overhead we ran into with Pendo.


Samren Salsa
·1 month agoThis is a pretty useful idea, especially for dashboards that get updated often. Having the notification right on the dashboard makes more sense than expecting users to check a separate changelog. I also like that each user can track their own read status, so one person clearing an update does not affect everyone else.
Garrett Wolfe
OP1 month ago@Mia Isaacson Thoughts on this?
Mia Isaacson
·1 month ago@Garrett Wolfe This is very cool! So this isn't coming from any backend events; it's all user-driven? I'm assuming that it's read-only for viewers and then CRUD for designers? Are items editable after they are added?
Answering the question below to Ido and Ravid... we haven't built anything yet, but it is something that we are exploring. There is a large gap between user actions on the dashboard and what Usage Analytics reports. We would likely be taking more of an event-driven approach.
What I'm seeing are two similar but nuanced use cases when it comes to dashboard activity/changes:
I arrive at the dashboard where I'm a Viewer, and something has changed. Something looks different, and I don't know when the change was made, who made the change, or exactly what the change was - this is what your solution is tackling
As administrators of dashboards who invest time in building, upkeep, etc., are users not only opening the dashboards, but are they interacting with the content? Are there specific actions that they are taking over and over that would indicate a need for additional, more focused information, etc.
#2 is where we would be more likely to address.
Garrett Wolfe
OP1 month ago@Ido Darnell @Ravid Paldi have either of you build something like this already?