New Conditional Fields app does not have "Required to submit/update" option, only REQUIRED TO SOLVE

4 Comments

  • Andrew Soderberg
    Comment actions Permalink

    Yes! We also love how the Conditional Ticket Fields now supports the native "Required" parameter...

    But please also add the following as soon as humanly possible:

    1. As listed above - Required field upon submit for any status. (managers and other agents can't get accurate current data/reports/views on open tickets if certain required fields are not populated until the ticket is solved).

    2. Required field for form A but not form B. (currently using separate fields to solve this limitation makes for analytics tracking nightmares)

    3. We have an auto-solve on pending (after many triggered reminders to the customer and agent) but we need to have some select Required fields to be able to prevent (or trigger notify agent prior to) auto ticket solve on pending after x days/weeks.

    0
  • Lori
    Comment actions Permalink

    Hi ,

     

    I need the function to make some of ticket field a required one when sending a public reply.

    Please add this feature!!!!!!

     

     

     

    0
  • Pedro Rodrigues
    Comment actions Permalink

    Hi Lori, here's an example workaround to do that ("TicketField1" is the custom field you want to check):

    Trigger 1 (new)
    Create a high-positioned trigger with the following:

    • ALL CONDITIONS: ticket is updated + current user is agent + comment is public + (any other elements that identify this workflow) + TicketField1 is not present
    • ACTIONS: add tag "requester_nonotif" + add tag "error_123" (this one's optional, see "Trigger 4" below)

    Trigger 2 (new)
    Below the previous trigger add another one:

    • ALL CONDITIONS: ticket is updated + tags include requester_nonotif + current user is agent + comment is public + TicketField1 is present
    • ACTIONS: remove tag requester_nonotif

    Trigger 3 (existing)
    Finally, add the following condition (under ALL conditions) to your trigger that notifies the requester. This trigger should be positioned on your trigger list somewhere below the previous two:

    • Tags contain none of the following » requester_nonotif

    Note: this also allows you to develop further use cases to prevent requester notifications :-)

    Trigger 4 (extra). You can also create a fourth trigger to notify the ticket Assignee of this:

    ALL conditions:

    • Ticket is updated
    • Current user is agent
    • Assignee is current user
    • TicketField1 is blank
    • Tags contain requester_nonotif
    • Tags contain error_123

    Actions:

    • Email assignee

    ----

    Of course, this isn't very scalable if you have more ticket fields whose presence is required in these situations (before solving).

    Also, and depending on how you have your requester template set up (i.e. all comments vs latest comment), the ticket assignee would probably have to convert their previous comment to an internal note. Then probably copy-paste and send it again.

    0
  • Zac
    Comment actions Permalink

    Thanks for the recommendation here Pedro. It's ONE workaround but really doesn't provide the feedback in the moment / in-experience. So while it helps maintain data integrity, it doesn't give the agent the immediate feedback of "this ticket is not done" that an error message in the UI would. It leaves open the following scenario:

    • Agent does not get the follow up message and leaves the ticket "undone" for an extended period of time or indefinitely.

    Further, it introduces friction into the agent workflow, requiring them to go back and repeat work that was not done, as opposed to getting friendly guidance in the moment that additional work is required. By the time this error is noticed by the agent, they may have moved onto their next ticket or even taken a phone call that generates additional follow-up work for them, starting the process of creating a backlog they will later have to recover from. As this error rate scales up (which is likely due to the lack of in-the-moment feedback) it impedes the overall efficiency of the call center.

    Thanks for the hard work and thought you put into the answer. I know it is the best workaround available at the time. What I would like to make clear to the owners of the product is that in-the-moment feedback and guidance is essential, and business owners / admins need the ability to set up flows for agents. Products like Zendesk that deliver a better customer experience should maintain focus on empowering the agent to do their job correctly, the first time. If the agent and admin experience aren't right on providing that frontline support, nothing else matters.

     

     

    0

Please sign in to leave a comment.

Powered by Zendesk