[OPEN BETA] Announcing a new request list experience Open Beta with improved filtering, sorting and column management

Return to top

50 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
    Hi CJ! If I'm understanding your question correctly, then yes this is a new version of the My Requests page for end-users in the Help Center. This does not affect Views in Zendesk Support; as before, agents & admins can see tickets they're CC'd on by going to their own user profile in Support, but not via Views (see Viewing your assigned, requested, and CC tickets in your Support profile).
     
    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
    User Group Leader

    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
    Zendesk Product Manager

    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
    User Group Leader

    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

    <div class="container">
    <header class="my-activities-header">
      <h1>{{t 'requests'}}</h1>
    </header>

    {{request_list}}
    </div>

    Curious about its customization, although considering your disclaimer above, I've noticed some of the following in its HTML:

    • data-garden-id (buttons.button, buttons.icon, forms.field, cursor.pagination)
    • data-garden-version. (8.35.0, 8.32.1, 8.34.0)
    • data-test-id

    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
    Zendesk Product Manager

    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
    Zendesk Product Manager

    Jake Edwards, 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
    Zendesk Luminary

    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
    Zendesk Product Manager

    Rafael Santos, apologies for not getting back to you sooner.

    Glad you like the feature so far!

    Is there more documentation on these? Will we be able to load Garden components natively?

    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
    Zendesk Product Manager

    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
    Zendesk Luminary

    Gorka Cardona-Lauridsen

    In our case there are primarily the following usability problems, which can be seen on this video:

    1. The list of additional columns, i.e. ticket fields, is much, much too extensive in our case if you can't restrict them. However, we need all these fields to be able to map the different ticket forms for our products, but we do not need these as columns in HelpCenter.
    2. Many of these ticket fields have different naming internally in the agent view, but for the customer this is very often only visible as "product" or "version". The customer, who uses product A, can only find out by trial & error, which of the many fields e.g. with the speaking designation "version" is relevant for his product used by him.
    3. The list for the selection of additional columns is currently not sorted alphabetically. Which sorting mode is currently used here and why?

    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
    Zendesk Luminary

    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
    Zendesk Product Manager

    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.

     

    The list of additional columns, i.e. ticket fields, is much, much too extensive in our case if you can't restrict them. However, we need all these fields to be able to map the different ticket forms for our products, but we do not need these as columns in HelpCenter.

    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?

     

    Many of these ticket fields have different naming internally in the agent view, but for the customer this is very often only visible as "product" or "version". The customer, who uses product A, can only find out by trial & error, which of the many fields e.g. with the speaking designation "version" is relevant for his product used by him.

    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?

    The list for the selection of additional columns is currently not sorted alphabetically. Which sorting mode is currently used here and why?

    That is a bug, we should sort it alphabetically. I believe it's probably by field ID right now.

    0
  • Gorka Cardona-Lauridsen
    Zendesk Product Manager

    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
    Zendesk Luminary

    Gorka Cardona-Lauridsen

    Thank you for your timely feedback as well as detailed explanation of the background.

    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?

    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.

    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?

    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.

    I'm curious to hear what you think?

    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
    Zendesk Product Manager

    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.

    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:

    We are working on adding tooltips as we speak.

    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

    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
    Zendesk Luminary

    Jake Edwards 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
    Zendesk Luminary

    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
    Zendesk Product Manager

    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
    Zendesk Product Manager

    Josef Prandstetter

    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?

    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
    Zendesk Product Manager

    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
    Zendesk Community Manager
    Hey Gulzar,
     
    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

Please sign in to leave a comment.

Powered by Zendesk