Sam

Gouthami Munugoti I think I'm encountering something similar, are you saying you aren't passing an email to the Requester field? 

Correction on my post, you can rename the report widget here:

Apologies, missed this on first go but should've seen it when i showcased the option to delete the report from the dash.

I want to preface that if there are methods to accomplish what I'm talking about, they aren't clearly documented anywhere.

Zendesk's new dashboard experience is being forced upon users by end of March 2025. This isn't a 1:1 experience even a little bit and I'm a bit confused why we're getting less functionality in the new dashboard builder than before. One of the main things that is missing is customization. We have a wide variety of users and use cases for reporting and the old dashboard builder allowed us flexibility. 

One of the main things: Naming your report widget in the dashboard could be done in the old view:

and cannot be done in the new view:

Why is this a problem? Well if you create a report for a dashboard that has a similar metric to another dashboard plus or minus some filters or whatever,  you would name it something clear so it doesn't get confusing when you go to add a report. The problem is that it now has your “clear” naming on the report widget in the dashboard which isn't ideal. The alternative is to have X number of  named “Ticket Count” reports, w/ potentially different filters / metrics used on them which also seems annoying. Suffice it to say: it's a none issue with the Legacy builder. 

Another thing, you can't remove the dataset from appearing in the widget:

This is something that can be removed in the Legacy builder. 

In addition, you can no longer customize the headers, the widget shape, or font size with the new builder. Here's what a report widget could look like with the Legacy builder:

^^^ none of this is possible with the new builder. 

 

Another big missing piece is the ability to configure the chart within the builder. This is nonexistent with the new experience and now, if you want to change anything with the chart, you now have to navigate to the report and back again to the dashboard which is a time waste.

Let's say you want to add a time filter to the dashboard. Here's how you'd do it in the Legacy builder: 
Click Add > Add Time Filter > select what metric you want to base the filter off of with a neat selection

The new builder is similar BUT the “time filter” selection is terrible UI compared to the old method:
 

But that's honestly, kind of a minor issue in comparison to how I used to be able to select what i wanted to be displayed in the time filters:

Legacy allows you to rename the header, change how the time selection is displayed, allowed for advanced ranges, etc.

The new method does this:

Why is this an issue? Because functionality that allowed me to customize for the user viewing the dashboard is now being taken away and replaced with a worse UX for some reason. 

Another strange design: deleting something from the dashboard. Here's how you'd do it in Legacy:

Here's how you do it in the new dashboard:
Click the widget > then what? go to where most people would think the “Settings”  gear icon right? oh no actually

It's here! Here in the most hidden spot:

Here's the kicker, this all came about from opening the new experience for the first time, I haven't even been trying to do a ton just yet so I'm sure there are MORE things missing that I was able to do previously.

I am not usually opposed to new experiences as they are often an improvement on the old but in this case, I'm being forced into a new experience that feels not fully baked. I am sure that Zendesk will bring many of these features and more back into the dashboard builder but my issue is that they aren't there when I need them to be there. 

Frankly speaking, this incentivizes me to stop using Explore and instead export my data to another BI tool. That honestly might be the goal for ZD to lessen the load on their side but frankly, it means that the Explore portion of my licenses is 100% less valuable. 

It's wild that Messaging is touted as an upgrade vs live chat when it still needs to function as a live chat yet,  it misses many live chat key features, one of the most important ones: making it clear what your users are doing.  

Messaging has the same UI as tickets, has statuses like tickets (which can be used during Messaging and when the conversation ends and moves to a new channel), but for some reason, has a completely separate button to complete a message “send” action. 

Visually, distinguishing Messaging from Tickets is difficult already if your users work in both. Sure, there are MANY signs, however, the issue is not the signs but what the signs are trying to make up for: lack of distinction between experiences. Messaging is great for async convos, but there are MANY users who still need live chat functionality and the ability to quickly distinguish where they are in an app and what functionality they have access to is crucial in a support setting. 

Here's the main glaring issue: if I'm in a Messaging convo, actively taking part in it as if it were a live chat (or otherwise), why are the most important actions the smallest? In addition, they don't have any outline, or distinguishing drop shadow, button-like resemblance, etc. UNLESS you hover over them. 

This a recipe for mistakes and can result in severe consequences, e.g. user types up their message > is used to being in tickets > changes  status > hits submit > customer never gets timely reply > SLA broken > etc. etc. 

Yeah, there are ways to mitigate it but, ultimately, it shouldn't ever be on anyone to build precautions and processes around a lacking core functionality that should be clear from release. 

Now as far as HOW this gets implemented I'm unsure. I'd love to re-purpose the area around the “Submit as…” button so that the “end session” and “send” are next to it or around it. Something like this in the bottom right: 
End Session | Update Ticket | Send Message

Whenever the Messaging session ends > use that action to update UI > goes back to normal ticket UI.
Connect the previous “Submit as…” functionality to the “Send Message” OR the “Update Ticket” functionality, e.g. user updates subject or field values or tags or status, clicking “Send Message” locks it in. 

I'm sure there's issues with that idea but the general message is the same: make the UI make sense for the action being taken on it.

This would be very helpful as some light agents (and agents) are unaware of the licensing nuances or forget so this would be key for understanding conversation history: that an email did actually go out, to the requester, or a 3rd party, from a light agent and wasn't just an internal note.