Dan Ross

+1000 to Colin's comment. I finally gave the new dashboard builder a try hoping that it would be more polished than the beta but this omission breaks my brain. Any kind of user testing should have validated the need to filter like this. 

This limitation and Decompose not being a thing  and a lack of ‘Quarter’ in the relative date filters in GA is incredibly disappointing. I'm going back to the legacy builder for now.

I try to stay positive with these releases but I am not convinced that Zendesk has any business setting an EOL for the legacy builder until its replacement is actually suitable for GA. Sorry Explore team, I know folks are working hard, but this release is just not ready for production use.

Are there plans to release Decompose and functionality to select all/exclude values from filters? Additionally, please add relative date periods for Quarter! Jumping from Month to Year is not helpful for the most common type of report, the QBR.

In its current state, the new builder does not work for our organization's needs.

Walter Bellante Am I reading correctly that Decompose functionality is not planned to be added to the new dashboard builder? I don't see it as a GA or Post GA item, yet it is under the ‘Most-used Features’ table. Please re-implement this!

This is really important for drilling into data and maintaining the same visual presentation as the source chart. The drill in workaround is poor, the drill in window uses like 25% of the screen(why so small!?) and is not appropriate for displaying more than a few columns or records. 

Raising this thread from the dead - we are also affected by users who are surprised at not receiving expiration alerts.

Please consider sending these emails to any user subject to a password expiration policy, not just admins/agents.

Thanks Karan Shah for the reply. 

It would be super if multi-select ←->multi-select sync existed, as text fields don't generate tags for workflow automations. Please consider this for future development!

Free text fields are the enemy of usefulness. 
 

Does this integration support mapping SF multiselect fields to Zendesk multiselect fields? Either way, can the chart be updated to indicate this?

+1, I've also struggled with this. Being able to sync the values from SFDC to Zendesk picklists could solve a lot of failed-to-sync headaches.

Some questions would need to be answered though including things like:

1. What happens if a value is deleted from a picklist in Salesforce?
2. What happens if a mapped value is deleted from a dropdown in Zendesk?
3. In either scenario, what happens to records that contained that value? What should happen?

It would also be great to get some kind of option to alert when syncs fail. I'd love to connect that to a Slack channel that fires alerts on failure. 

We're very glad you're back Agnieszka, hope you are doing better!! The community really appreciates your quick reply and updates for this issue, as well as for sharing there's a plan to improve.



 

Thank you Agnieszka Pyzik for replying to this post so quickly, it's really appreciated!

I look forward to having it rolled back on our account. Additionally, I'd like to share some thoughts that might be helpful as the team works to refine this offering. 

1. Release notes need to be updated for all changes. Some admins operate in regulated or controlled environments and need to be able to point to a release note showing specifically when something changed. An in-app message when opening views for the first time after the change was deployed to explain what's new would have been another great way to change-manage this. 

2. IMO the older a set of functionality is in the system, the more heads up should be given about a change as it will impact more workflows. Views and their configurations have remained relatively static for years. All that to say, a heads up to admins that a frequently used configuration was changing would have been nice.

3. The way in which # of columns was indicated in view setup was not clear. How is a user supposed to know that Ticket Status does not count towards their column limit? Should the counter now indicate that the maximum value is instead 11? 

As a related question - In your screenshot showing the duplicate columns, I notice you have nested Views natively. How can we get that behaviour?



Thank you

Hi Zendesk Product team,

I just finished working with support (Ticket #12896498) in which I was told that a recent UI/UX change we're seeing is intentional. I was advised to share feedback about this change here, so here you go!

What changed?

This change requires any ticket view to have a mandatory Ticket Status column. It cannot be removed, only the position adjusted. Not only does it appear this change wasn't announced (?!) it's hugely regressive to administering the system and demonstrates a lack of awareness as to how your customers use your platform.

What's the impact? Why is this is an issue?
We create views for different tickets with the status filtering put into place in the view parameters itself (ex: Status = New). This means that anyone viewing the tickets there can safely assume the status is New and it's not necessary to include a column for it.

The impact is that we cannot display as much data as we used to, because we are forced to devote a column to data that is not needed in our structures. Additionally, we use Lovely Views (as do many of your customers) to manage our views properly. Lovely Views displays status on its own, without forcing us to take up one of the 10 precious columns we have available for data.

The Ask

1. Revert this ASAP please. Please don't assume which data should be shown about tickets on our behalf. That's very organization and configuration dependent.
2. Log all changes in your release notes.
    

Below is what a Lovely Views user would see.