Recent searches
No recent searches
Required fields are not really REQUIRED
Posted Jun 23, 2022
For some odd reason, We are able to respond to a ticket without the agent being alerted to update the REQUIRED field. Please fix this as soon as possible as this is a major operational challenge.
Screen video example below:
4
18
18 comments
Ryan P.
Just another end user here; but I believe it's only required to "Solve" the ticket, not for submitting during any other status. Certainly would be nice to have a distinction between the two.
EDIT: To expand, if the field is required for end-users (on a Form), then it is required to submit the request right away. So there is a difference between required for agent and required for requester.
0
Lou
Jeff Stephenson
Ryan P. is correct. To add to it, you can use triggers to "force" a required field. The conditions depend on your needs, but you can change the status to Open and email the assignee/agent that the field was not entered.
We use this to reopen a ticket if a field we want entered when solved was not. Works great.
0
Konstantin
Ryan P. and Lou,
It depends on how the Fields are configured, as I am running into a similar issue (I have an active ticket open with Zendesk Support team) since the release of the new Field behavior with Agent Workspace. The issue is that you don't set a Default value, but the system is auto-setting the "NULL" (i.e. " - ") value as a valid default Field option, and thus the "Required" is no longer required by a person. Since the "Required" is being sufficed by a default value being set, the system doesn't care if a person makes a selection or not.
~Konstantin
2
Jeff Stephenson
Thank you. Is there a way to have the trigger stop the message from being sent to the customer if the required field was not selected? In this example the dropdown is suppose to insert the specific required field property into the message and sometimes these tickets need to be sent as "Pending". Can the trigger halt this and for the agent to select the required option? I'm baffled why these are called "required fields" in the first place.
0
Konstantin
Jeff Stephenson,
They use to work as "Required", until about a week or so ago (at least for my company). Also, I noticed this seems to only occur within the Agent Workspace environment, as we utilize two instances where only one uses the Agent Workspace functionality, while the other uses the old style (has Agent Workspace enabled for implementation, but not turned on for Agents).
As for your Trigger rule, depending on how it is built, you could look at just adding the Condition of "<specified field> is not " - " " and that should ensure it doesn't perform its actions at that time.
~Konstantin
2
Konstantin
Jeff Stephenson, Lou, and Ryan P.,
After being on a Zoom call with a Zendesk Support agent, I now better understand the issue at hand...
Prior to the recent Fields section changes, the behavior was:
"Required to Submit" is set for both Agent and End User
"Required to Solve" is set for both Agent and End User
While the new behavior is:
Agent allows for "Required to Solve"
End User allows for "Required to Submit"
It is nice to have them broken out, but the "Required to Submit" option should also be set to the Agent section as well, as we utilized a bunch of "internal" Forms that we require our Agents to fill out. As such, the new behavior should look like:
Agent allows for "Required to Submit" and "Required to Solve"
End User allows for "Required to Submit"
Having to go and generate a ton of Form Conditions and/or Triggers to support Agents being forced to set Fields for submitting their ticket is not a viable option for us.
~Konstantin
5
CJ Johnson
It would be great if Zendesk would announce changes like this to the product, perhaps in the weekly release notes. This is a huge workflow change that will impact us heavily and this is the first I've seen anything about this.
1
Konstantin
Lou (et al),
I believe I found another reason this issue is now occurring; Prior to the changes to the Fields section, Fields that allowed for selecting a "Default" value had a "Set as Default" flag next to each listed option, and could be selected or un-selected as needed.
With the new behavior, there is a drop-down pick-list at the bottom of the Field configuration page, which appears to auto-select the " - " as the "Default" value, just in case no value is selected. I say this, as the " - " has a checkmark next to it when viewing the list, and if I select another value, the checkmark now moves to that value.
Since the system sees this as a valid "Default" value, the requirements for the Field are now considered as "met", when that is not the case (we are looking for the user to specify a listed value that is not " - ", as this is considered a "null" value generated by the system).
~Konstantin
3
Julie Force
I have a drop down that I need to require for the end user to submit a ticket. It is important that the end user specify one of the two options and if I set a default they will skip the question entirely and not update the field to the correct value. However, if I set no default, Zendesk assumes that the blank value is a choice and does nto require the user to choose from the two actual options. How do I work around this issue?
3
Asaf Max
I too would like there to be the ability to set the required to submit on the agent level. We have internal staff from different departments creating tickets on behalf of an end user without filling in required fields, causing the agent that handles the tickets to chase after them or the end user for the missing information. This causes delays and gives off a negative end user experience as they would expect us to already know the information that we are requesting (since it is one of our internal staff that is creating the tickets).
1
John Watts
We're having the same issue with this. A drop down field is set to required to submit ticket with a default value of null/ " - ". Users are able to submit tickets without changing the response from " - " to one of the field values. Zendesk is treating " - " as a valid response.
The field value drives group assignment automations, so tickets created with the " - " value have to be manually reassigned by Admins which is a waste of their time.
1
Permanently deleted user
Hello any updates about mandatory fields in ticket?
why we can't set a field as mandatory (without condition)?
I mean I just wanted to set a field as mandatory not only for submit as SOLVED ticket
0
Zsa Trias
Hello Saasten,
If the field is also editable for end-users, there would also be an option to require the field to be filled out by end-users upon submission:
More details about this here: Adding custom fields to your tickets and support request form
0
Permanently deleted user
Hi Zsa Trias
Sorry, I mean makes the field directly mandatory without using conditions (as an agent)
0
Zsa Trias
Hello Saasten,
I see, there's no native setting to make a field mandatory for agents aside from when solving them, but you may want to check this app from our marketplace: Ticket Field Manager
This app allows you to hide, require, and disable certain ticket fields and drop-down options in the Zendesk Support agent interface. More details about the app here.
0
Mark de Leeuw
We are facing the same issue as John Watts quoted above: The field having the '-' value as a valid response for Zendesk purposes really messes up our workflows and enables our customers to submit tickets without information that we need. Sending an email back asking them to fill in the field afterwards is a no-go for us. Is there an ETA for Zendesk to improve this, since it feels like this is a key feature that is no longer working as intended?
0
Sharuk Ahmad
We are facing the same issue as John Watts & Mark de Leeuw, this is resulting in a lot of manual work & in-efficiency. End users are submitting tickets with required info. being '-' value, when in fact the field validations should work properly. Please provide an update on a fix or a workaround.
0
Gaurav Parbat
Hello all,
We are working on capabilities to introduce record and field level permissions. This means that we are working on adding it as a priority later in our planning cycle for 2025. We are going to leave this post open for comment to allow others to provide their feedback and use cases, however please note as is stated in our Community Guidelines that we can not commit to a planed release date on any one piece of feedback we receive in the community.
0