Announced on | Rollout starts | Rollout ends |
---|---|---|
June 27, 2022 |
June 27, 2022 |
July 6, 2022 |
We are happy to announce an improved request list experience with better filtering, sorting and column management. This release is phase 1 in a series of releases to improve request management for end users. See also the feature documentation.
Why did we build it?
While for many end users with one or a few requests, managing their requests is doable with the current my activities page, there is a group of power end users that manage many more tickets, sometimes hundreds. These end users are typically managing tickets on behalf of a department or organization often as customers of a B2B vendor.
Managing hundreds of tickets has been painful for these end users and now we are taking the first step in upgrading the customer portal to enable ticket management at scale.
What is it?
With this first release of an improved request list in the Help Center we are adding 3 new combinable filtering options, the ability to sort more columns and the ability to show/hide columns.
Combinable filtering
We have added three new filters to “My requests” and “Requests I’m CC’ed on” so you can now filter you tickets on when they were created, where they were last updated and which organisation they are in.
Under “Organizational requests” we have added the ability to filter by when requests where created and when they where last updated in addition to the existing organization and status filter option.
What truly multiplies the value of these new filters is that they can be used in combination and you can set multiple values for the same filter to create an OR filtering condition. For example you can now filter on tickets within the Organization ABC OR Organization XYZ that has the startup Open and is updated in the last month.
Improved sorting
Now you can also sort your tickets by “Status” and “Created date” in addition to “Updated date” by clicking on the arrows above each column.
Manage columns
A completely new feature is that we are now allowing end users to show/hide the column they want to see. You can still filter on columns that are hidden and the sort order is maintained when you hide a column that is sorted by.
How do I start using it?
If you are using a Copenhagen standard theme, your theme will review the update before the end of the rollout period indicated at the top that will enable you to turn on this feature if you wish.
Here you can find a description of how you enable the new request list experience for Standard and Custom themes.
What does it mean it is in Open Beta?
That the feature is in Open Beta means that anyone can opt in to using the feature as described above, but the feature should be considered in a Beta phase where we are aware that it still has key limitations.
Known limitations
- Look and feel Customization
- The new request list is rendered as an encapsulated component, which means that it is not customisable as other advanced helpers by targeting the HTML. We have done this to allow for quick iteration of the feature without breaking any help centers. This comes with the limitation that the look and feel of the new request list experience is only customisable through theme settings where the component inherits colors from the settings the same way that the previous request list experience does in the Copenhagen theme.
We are working on enabling better look and feel customisation.
The good news on this is that to build the new request list experience we have allowed querying of the Requests API by end users. This means that anyone can now build a similar experience, a better one or a more custom one, exactly as they like using these APIs.
- The new request list is rendered as an encapsulated component, which means that it is not customisable as other advanced helpers by targeting the HTML. We have done this to allow for quick iteration of the feature without breaking any help centers. This comes with the limitation that the look and feel of the new request list experience is only customisable through theme settings where the component inherits colors from the settings the same way that the previous request list experience does in the Copenhagen theme.
- Combining multiple org filters
- In the “Organisational requests” tab you cannot combine organisation filters to see tickets from more than one organisation in the same list.
- In the “Organisational requests” tab you cannot combine organisation filters to see tickets from more than one organisation in the same list.
- API rate limiting
- The new request list is rendered client side and uses public Zendesk REST APIs, mainly the Requests API, which means that it is currently subject to the account's rate limit. Our data shows that the majority of accounts and end users will never be affected by this, but we are intending to solve this limitation.
- The new request list is rendered client side and uses public Zendesk REST APIs, mainly the Requests API, which means that it is currently subject to the account's rate limit. Our data shows that the majority of accounts and end users will never be affected by this, but we are intending to solve this limitation.
- Custom ticket status support
- The new request list does not yet support Custom Ticket Statuses (CTS) that is currently in EAP, but we will add support for CTS.
What’s next
This is just the first Beta release to improve the request list experience. Next step is that we will enable you to easily configure that your end users can see specific custom fields in the request list and allow end users to apply the new improved filtering, sorting and column management to those custom field columns. Stay tuned!
Want to learn more?
See the feature documentation.
51 comments
CJ Johnson
Is this update specific to the "Requests" page that is only available if your users sign in? Will Zendesk be implementing this in their own Requests page as well?
0
Dave Dyson
There's a product feedback thread on this, in case you'd like to add your use case: Feature Request: Add cc'ed tickets as condition in views
0
WhatsApp Connector
Hello,
I am unable to see the request list section within settings when customizing a Copenhagen theme. Please let me know when you expect this option to be rolled out to all the environments.
Thanks.
0
Rafael Santos
Hey Guillermo, note that the rollout ends on July 1st, so it might not yet be enabled for you.
As per the instructions above, the feature documentation has a section on
After the deployment is completed, you'll have the request_list helper available, which can be placed in your theme's requests_page.hbs file.
0
Gorka Cardona-Lauridsen
Rollout to existing Copenhagen Standard theme users has taken a bit longer than expected and is currently in progress. We expect everyone with a Copenhagen Standard theme to be have the new request list experience option available in their theme settings latest July 6th.
Everyone can at this point use the {{request_list}} helper in custom themes and also try the new experience by downloading a fresh copy of the Copenhagen theme.
0
Rafael Santos
Thanks for the update, Gorka Cardona-Lauridsen.
It's looking great for us! I've followed the latest release's template, replacing everything in the requests_page.hbs with these 7 lines
Curious about its customization, although considering your disclaimer above, I've noticed some of the following in its HTML:
As far as I understand these are for the Zendesk Garden Components, specifically from Garden 8.
It seems like they're being loaded by the scripts "vendors-guide-requests-app(...).js" and "react-(...).js" (loading React 17.0.1)
Is there more documentation on these? Will we be able to load Garden components natively?
0
Jake Edwards
Cool. Long overdue.
Where do we provide feedback?
Our customers constantly ask for exports of this list.
0
Gorka Cardona-Lauridsen
Happy to let you know that we have now added the ability to see custom field columns in the request list if the field is set as editable or viewable by end users.
Read more in this announcement.
0
Gorka Cardona-Lauridsen
@..., you are welcome to add your feedback here in the comments if you can share it publicly, it may also be useful for others.
If you prefer it not to be public you can add feedback to this form.
Thanks!
0
Josef Prandstetter
Hi Gorka Cardona-Lauridsen,
First of all, thank you for providing this great feature - it really is a significant improvement for our customers/partners to use the help center more efficiently.
However, we have a lot of different ticket forms in our Zendesk instance which require well over 100 ticket fields (visible to customers).
We have a clear need that we want/need to limit the list of fields in addition to visible and editable for customers - do you think it is possible that you map with an additional parameter instead of using the current existing parameters?
4
Gorka Cardona-Lauridsen
Rafael Santos, apologies for not getting back to you sooner.
Glad you like the feature so far!
You are correct about it being Garden REACT components. We are working in the direction of allowing native loading of Garden components eventually, but there is still quite a bit of way to get there and some hurdles to overcome so unfortunately I can't promise anything for now.
0
Gorka Cardona-Lauridsen
Josef Prandstetter Thank you for your feedback!
I'm curious about why you need to restrict the number of fields end user can show/hide beyond the field's editable/visible setting?
0
Josef Prandstetter
Gorka Cardona-Lauridsen
In our case there are primarily the following usability problems, which can be seen on this video:
If you are interested, we are available for a web meeting to explain our situation and practical examples in more detail.
3
Jake Edwards
Can we please get Requester added? This is useful in the organisation requests view where they may be many tickets submitted by different people.
4
Josef Prandstetter
Gorka Cardona-Lauridsen
We would also see a value in adding the "Requester" for organisation requests as mentioned by Jake Edwards above.
In addition, during an extensive discussion about this new function, the question arose whether it would be possible to include the name of ticket forms as an additional column in addition to the ticket fields.
When customers/partners submit tickets via HelpCenter, we primarily distinguish which product they have a question about or report a problem with.
Exactly this information is used by our customers/partners, who have a high ticket volume, to sort and filter their requests.
We know that there is a workaround for this by synchronizing this information into a separate ticket field, but we actually see this only as a workaround, which we would like to avoid.
4
Gorka Cardona-Lauridsen
Josef Prandstetter Thank you for the very thorough elaboration on your feedback!
I will definitely not rule out adding an additional parameter to include or exclude particular fields, hence we are in only beta, but there are a few aspects of this issue I need to understand better and there are a few things we are planning to introduce that will address at least parts of the problem. See below.
Setting aside the issue of duplicate end user names (see next) we are initially approaching the usability aspect of this with a priority to give the primary end-user maximal flexibility.
We have chosen this priority because the primary end user for this feature is a power user that regularly uses the help center customer portal including the request list page where they manage 50+ tickets simultaneously. We believe that this type of user will value the flexibility of access to all fields possible over the complexity that it brings when initially having to set up a view or occasionally having to change it.
Therefore we have chosen by default to include all fields that they would have access to see or edit and as a next step we want to make it easier for them to configure their view by adding add search for fields when you show/hide columns.
Right now view settings are stored in your browser so if you use the same browser and do not clear the cache your view will persist from time to time that you log in, reducing the need to reconfigure your view. However, we are also considering adding user-specific saved views to further decrease the need to set up a view more than once.
As mentioned I will not rule out the possibility of adding another parameter, but I have high hopes we can address the usability issue of many fields with these improvements.
If we were to add a new setting to the field, how would you feel about the default still being that a field was visible in the request list if viewable or editable by end users and the setting would exclude a specific field if enabled?
This is obviously a problematic issue. Forgive me for wanting to dig a bit deeper. I'm curious about what the reason is that you need to have multiple fields called (for the end user) "version" or "product" etc. and cannot use the same field across all ticket forms?
As I think through this problem, merely restricting certain ticket fields for end users in the request list will not solve this issue. Removing all fields from the request list that have duplicate end user names would remove the clutter, but at the same time make those fields useless for overview purposes which I think is worse than having to trial and error a few times to get the view you want.
This leads me to the conclusion that the optimal way of solving this is to either use one field for the same type of data point across all forms (if possible) or to make each end user name unique by using a prefix.
The third alternative I see would be to only show fields where the user has tickets containing a value in that field. That would not necessarily eliminate duplicate field names for the end user, but it might in many cases. This alternative does not exclude the two others.
I'm curious to hear what you think?
That is a bug, we should sort it alphabetically. I believe it's probably by field ID right now.
0
Gorka Cardona-Lauridsen
Jake Edwards and Josef Prandstetter
I have taken note of your feedback to add Requester and Ticket form and we will add them if nothing gets in the way however I can't give you an ETA right now. We chose to get custom fields in there first because it is the most flexible and allows for workarounds for specific use cases like this, but I agree that eventually these fields should be included natively.
0
Josef Prandstetter
Gorka Cardona-Lauridsen
Thank you for your timely feedback as well as detailed explanation of the background.
I agree that probably for the majority of all Zendesk customers who are interested in this feature it would be less work if the default value is that all fields are visible.
With a ticket form, we only select the parent product family.
Below a product family, we then have different products and modules, each with their own version number range. Both the list of products, modules and version numbers are mapped by means of drop-down lists for usability reasons and are therefore available many times within one Zendesk brand.
The matter with the ticket fields for end users is a special case: This is needed because business partners have to name the respective end customer when submitting issues. Of course, each business partner has its own list of end customers, which must also be mapped using drop-down lists.
In our case, restricting ticket fields would increase the usability, because many of these fields are only needed to efficiently dispatch of tickets and to be able to create meaningful analysis/statistics afterwards. However, these fields have little or no added value for the end customer or partner in the ticket overview.
Another option instead of restricting ticket fields could be to configure your own descriptive name for the request list.
Another thing we noticed is that currently custom fields do not have a tooltip on mouseover if there is not enough space to display them completely:
I will probably know the answer, but is it planned that an end user can freely define the order of custom fields/columns? That means instead of column order A-B-C-D e.g. D-A-C-B
You are very welcome to create test tickets yourself on our global support platform so that you can test the current status.
0
Gorka Cardona-Lauridsen
Thanks Josef Prandstetter! I think I understand the issue very well now and I see definitely the need. I will be honest with you that with the data I currently have and the current state of the feature there are other improvements I plan to prioritize before this among them the improvements mentioned above as well as the ability to filter and sort custom fields. Still, I have taken note and have it on my list.
To anyone following this discussion that has the same issue, I would encourage you to chime in this thread with your use case to limit the number of fields further.
We are working on adding tooltips as we speak.
This is a great question. We have initially gone with the simplest solution that the order is fixed and are awaiting feedback on how necessary that is or isn't and why, so please share if you have an opinion on it :)
0
Jake Edwards
Gorka Cardona-Lauridsen thanks.
Yes, our request (understandably) wouldn't make sense from the My Requests screen, but definitely does from Requests I'm CC'd On and Organization Requests one, so as long as that's clear.
Our customers are now reporting the missing column now which was visible before the beta.
Is there a timeline on a fix to restore the functionality in the beta?
1
Jake Edwards
Gorka Cardona-Lauridsen, sorry for the multiple posts, but the feedback keeps rolling in!
It seems end users can no longer filter/see Status on their side?
This is also a missing feature that was there previously. Will that be restored?
Update: We've left the beta as the features missing are too useful, and we had so many questions around where they went!
4
Josef Prandstetter
@... we see the same issue - here you can find our post:
https://support.zendesk.com/hc/en-us/articles/4628113350170/comments/5085821095834
2
Josef Prandstetter
Gorka Cardona-Lauridsen
The current situation is that each customer has to configure the required columns for each browser if they need more information than the standard.
Is it possible for Zendesk Guide administrators to pre-define the list of columns per HelpCenter, so that most customers do not need to make any further adjustments?
In our case, the same columns/fields always represent added value, and from a usability point of view, it would of course be a good idea to make this available to customers right away.
This would also mitigate our problem with the many fields that have the same name.
0
Gorka Cardona-Lauridsen
Jake Edwards
Apologies for the late update on the bug. We rolled out a fix for the missing Status column bug last Thursday.
0
Gorka Cardona-Lauridsen
Josef Prandstetter
I can definitely see how that would improve the usability of the request list and I have recorded your feedback, but I can't promise we will implement it or when.
To be completely transparent about how I think about its priority, we are right now in the first phase of developing the new request list experience where we are prioritzing to "make the impossible, possible"; showing, filtering and sorting new system fields and custom fields, advanced customization, etc. that we believe give the most value to our customers fastest.
Once we have made the "impossible, possible" we will start focusing on making the "possible easier" which is where I see this improvement fit in.
1
Gorka Cardona-Lauridsen
Hi all
We are very excited to announce that users can now (pending rollout) filter their requests based on custom field values in the new request list experience. See the announcement here for all the details.
0
Jake Edwards
Still no love for Requester column? That's one of the last columns for parity with current experience.
Requester is useful for Requests I'm CC'd on and Organizational Requests.
1
Gulzar Shikalgar
Is this feature rolled out to all users, or still in beta? Any estimated date when this will out of beta and available to use?
0
Brett Bowser
This is still in open beta so if you're interested in participating, you can take a look at this article that goes over activating this functionality: https://support.zendesk.com/hc/en-us/articles/4628113350170-#h_01G5FA1SWND2818Y9G9942W4QX
I hope this helps!
0
Tanawat Oonwattana
Do you have the timeline to have Custom ticket status (CTS) available for this feature?
thanks.
1