David Wexelblat

Re the comment above… My solution to this issue was to have 3 categories:

• Pre-Notification Status Changes
• Notifications
• Post-Notification Status Changes

So far this has sufficed to let me both categorize and adjust execution order to make triggers fire the way I want them to. Our implementation of Zendesk is pretty basic, so maybe this won't suffice for other use cases, but it's a suggestion.

I cannot possibly upvote this enough. A basic requirement for the new dashboard builder should have been “can we reproduce the functionality of the existing stock dashboards with this new tool”. That this was Requirement Number 1 for the new dashboard builder is baffling. That the legacy dashboard builder is being obsoleted while this level of capability is still absent from the new dashboard builder is simply incomprehensible.

Problem Category: New Dashboard Builder features

Problem Description: 

“Last 30 days” time filters on the new dashboard aren't actually “Last 30 days”. They're actually “from the day of the month last month to today”. For example, if I have a dashboard showing “Last 30 days” today, what it's actually showing is Feb 14, 2025-Mar 14, 2025.  That's 28 days, not 30. “Last 30 days” should be Feb 12, 2025-Mar 14, 2025.

This was discovered after a day of back and forth with Zendesk support trying to figure out why my custom dashboard, which is built as a subset of the stock “Zendesk Support” dashboard wasn't display the same results as the stock dashboard, using the exact same stock basic reports.

The legacy dashboard does yesterday back 30 days by default. The new dashboard does today back to the same day last month, regardless of how many days there are in the month.

We confirmed this behavior by manually setting matching date ranges in the “Zendesk Support” dashboard and my custom dashboard. For any manually-selected date range, the results matched up.

Maybe I'm weird, but I expect that an option labeled “Last 30 days" to actually do “Last 30 days”, regardless of how many days there are in the month.

Severity:  Medium

Problem Category: Components missing in the Importer Tool

Problem Description:
Removal of the Top/Bottom functionality in the new dashboard builder significantly reduces interactive analysis.

For example, we have a custom ticket field for “Issue”. I want my dashboard to show, by default, the top 5 Issues within the selected period of time, to keep things compact, but allow the user to select the Top/Bottom N for more detailed analysis.

The fact that the report has Top/Bottom selectors is completely irrelevant, as that simply creates a static report of that size for the dashboard.  The only possible workaround with the new dashboard builder is to have a static top 5 report on the main dashboard tab then put the full issue report on its own tab to be manually analyzed.

Severity: High

Perfect. Thank you.

Walter Bellante How about addressing concerns raised about capabilities of the old dashboard builder that are completely missing in the new one and marked as not-planned in your table above? For my usage in particular, removal of top/bottom is painful and there is no viable alternative. 

I am trying to figure out how to hide the author in search results.  This article suggests simply commenting out the author's name in search_results.hbs, which of course I can do. But I want the behavior to be controlled by theme's settings (i.e., settings.show_article_author). But when I wrap the HTML in search_results.hbs with the appropriate conditional:

{{#if settings.show_article_author}}
<span class="meta-data">{{author.name}}</span>
{{/if}}

I get an error message trying to save:

not possible to access `settings` in `settings.show_article_author`

I feel like I'm missing something obvious.

Walter Bellante How can you be obsoleting the legacy dashboard builder when the new one is clearly deficient in many ways that have been expressed in the comments to this article?

The fact that the existing stock dashboards can't be implemented with the new builder should have been a clear sign that it's not ready for launch. The ability to do what can already be done should have been requirement #1 for development of the new builder.

I live in terror of Zendesk doing the same with the new report builder, which is currently woefully deficient…

This is a defect in the marketplace. It shouldn't matter that the template comes from a third party. The purchase is done through the marketplace UI, and there should at a bare minimum be a confirmation of purchase from the marketplace itself. And you should require vendors to provide receipts. Customers should not have to reach out to get a receipt.

I purchased a theme for my company on my personal credit card, to be reimbursed by my company. I was beyond astonished that the purchase went through with no acknowledgment whatsoever. I found this article by searching for the issue and did get a receipt after reaching out to the vendor. 

But a web marketplace that provides no purchase acknowledgment on its own is just broken, IMHO. This is ecommerce 101.

How is the autorepy out-of-hours example above any different from simply putting 

{% if ticket.in_business_hours == 'true' %}
{%else%}
{%endif}

in the standard “Notify requesters and CC of received request” trigger?

And to whom does the autoreply go? To the requester, or to requester & CCs? If it's just to the requester, it's less functional than the above.