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

8 Commentaires

  • Andrew Soderberg
    Actions pour les commentaires Permalien

    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.

  • Lori
    Actions pour les commentaires Permalien

    Hi ，


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

    Please add this feature!!!!!!




  • Pedro Rodrigues
    Actions pour les commentaires Permalien

    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


    • 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.

  • Zac
    Actions pour les commentaires Permalien

    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.



  • Jane Griener
    Actions pour les commentaires Permalien

    PLEASE add this feature.  This creates data integrity problems when you cannot control what fields are updated until the ticket is solved.  We use data from Zendesk to integrate into several other systems.  If we can't require that fields are not empty, it makes the integrations pointless.  Thank you.  I feel this feature is basic and very important. 

  • Kevin Stafford
    Actions pour les commentaires Permalien

    Adding to the list of users asking for this! Having fields required for ticket update is absolutely vital for our data collection. Completing the required fields by trigger does not provide the necessary issue attribution we are looking for our agents to apply. Please let us know if and when this feature will be added to conditional fields. 

  • Zac
    Actions pour les commentaires Permalien

    Hi all,

    These release notes indicate that this functionality is being developed and is releasing to EAP soon:


  • Kevin Stafford
    Actions pour les commentaires Permalien

    This is great news Zac. Just signed up for the EAP. Thank you!


Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk