Allow end users to update fields after ticket is created


  • Christopher Reichle


    It's actually been over 8 years that this topic has been open. Fear not! It may seem like a really long time with no resolution but I can assure you that there are other topics that have been open for far longer (many years more) with 16 pages of comments that have still not been addressed. It is completely normal here. This lack of attention in no way means this topic is dead... nor does it mean that this issue is not a valid one, important, affecting a large portion of the user base and clearly an obvious flaw that should be addressed. However, this is the ZD forums where good ideas go to die. It's just not this topics time. It's not dead yet. This topic is still in the early phase. If we get up to 5 or 6 pages someone from ZD will maybe tease that they are looking at it or a moderator may chime in telling everyone to keep pushing. This in no way means anything is going to happen. It is just the next phase. They really don't like to say no at ZD so it will just remain an open sore, a scab that users will pick at every now and again.

    I believe that this and other "features" that people complain about are there because of limitations in the core of the product. If it were easy to fix I think they would. I don't think they are purposely ignoring us. It is just that they look at these issues and know why it is the way it is and know that its not easy to fix. The issue really is that they need to either bite the bullet and start addressing the hard to fix issues or just tell people we would love to but the way the product was developed limits out ability to change this feature. It's not going to get addressed. Then we all know where we are and can make choices and move on with our lives. Instead, they develop features that no one asks for or wants but are easier to develop and then try to up sell those features. Leaving these topics open for years is just insulting to your loyal base and, in a public forum, exposes ZD horrible customer service and lack of respect for their loyal base of paying customers. Honestly, if I had seen these threads going on for years I would never have started with ZD. Both because of the basic issues with the product that are exposed and the lack of response from ZD. Totally embarrassing. If I were a competing product my comparison sales brochure would just be a link to a few of the ZD forum posts going on for 15 years. 

    I really wonder what is going on over at ZD. Who in management thinks its ok to have a request topic open for 10 or 15 years. It is just the wrong way to handle it.

    By the way, I believe the official work around that our customers (end users) have implemented is to just create another ticket with the right subject or the right priority. So now we deal with a bunch of duplicate tickets that are just slightly different. When you contact the customer about the duplicates I usually get, "well your stupid ticketing system wont let me change... so I just created another ticket". Totally efficient and not at all embarrassing. Honestly, there are far more serious issues with the product to get bent out of shape over. 

    Welcome to the forum. I see your kinda new here. Initially, I just used the product without really implementing a lot of it. After a few years I dove in head first and tried to implement a lot more. As I ran into issues I discovered the forums and found others with the same issues. Some of my issues were resolved by solutions others posted. Some were just issues that I was able to confirm were not just happening to me and really were not going to get addressed. The part that started to piss me off was where you are right now with the outrage that an issue could be on the forum for 8 years without a response from ZD addressing the issue. That is followed by the frustration that your problem is real, others have it, it is impeding you moving forward and its just never going to get addressed. Keep exploring the forums. You may find solutions to your problems from other posters but generally, what you will come to understand is that  topic that is not addressed in a "reasonable" amount of time is never going to be addressed. Some people hold out hope because after 5 or 6 years someone said development was looking at it but after another 5 or 6 years those users become disgruntled. Sometimes a third party will solve the problem with a paid addin but I never like to go that route because those solutions can break as the product develops. 




    I find your 

  • David Shedd

    This is so unfortunate. One of the most critical functions to any support these days is an online customer knowledgeable/portal. It is also important that the client can take the control into their hands and not have to wait on a support rep to make changes to their ticket. Due to this limitation we must continue in this hybrid world of manually updating tickets for clients between email and an online support system. Here are just 2 business cases for the development team at Zendesk.

    Ticket Creation and Priority Setting

    We have been providing our clients an email address to our support for years to open a support case. We ask our client several questions as part of the ticket creation process that helps us determine priority, as well as potential support paths. This typically requires a lot of back and forth between the client and the support rep via email to figure out the urgency of their request. You can enable these questions/fields on the ticket creation page in the customer portal, which dramatically speeds up this process. Furthermore the portal will make article suggestions to the client which could solve their questions eliminating any support need at all. The holy grail.

    However if a client still emails a support email address without this information, we cannot have it create the case and simply point them to a link to update these critical fields in the portal after ticket creation. We have to fall back on old ways of taking the case in, contacting them, and having our support reps fill in these fields manually to prioritize their ticket, as the fields are not editable in the portal after ticket creation. If we change our support email to a bounce back email saying please go to the portal and add your request there, this will make them unhappy, as they need to recreate the wheel. If they recreate the wheel and make a mistake in the process of choosing the wrong value and they cannot correct this, you will have mad customers on your hands (this has happened to us).

    Ticket Escalation

    In our older support system, our clients could edit the priority field in the portal after ticket creation to escalate their ticket if the issue had become more critical. They cannot do that now, as they cannot edit their field. They need to contact us, we need to do it manually, etc.


  • Pascal Turmel

    Pretty basic feature. A Customer should be able to self serve and update the priority of a ticket simply by toggling the field in the Zendesk Portal as opposed to add a comment to request someone to do so...

  • Deepesh Chaudhary

    We want to provide our user with a flag which they can choose to escalate the case. This can happen after the case has been created and for some reason user wants to escalate the case. For this user(customer or staff) edits the case and checks the escalated flag and we can create triggers so when this happens we notify our support org. once things are brought to normal, customer and our support team should be able to de-escalate the case by unchecking the flag.

    also key to feature would be to able to report on it and have a history as to find how many cases were ever escalated.

  • Sample User

    Yes, you can create a trigger to allow updates. It's not an ideal workaround, but it does work...

    The way we set things up was anytime a particular string of text was entered in a comment, to increase (or decrease) the priority. The text string we chose was a keyword preceded with a number sign/hash (#) - ex: #urgentpriority, #lowpriority

    Where this workaround gets clunky is that you need a trigger for every option in a particular field....

  • Lesley Heizman

    I would love to give end users the capability to update certain fields in the activities area of the portal. As others have indicated above, we have end users that will log a request and then realize they have entered the wrong priority type and right now there is not a way for them to update it unless they create another ticket to bring it to our attention, specifically if let's say they needed immediate assistance and selected the wrong priority. Would love to be able to pick/choose which fields they can edit, much like the end user editable flag on the ticket fields perhaps another flag that would say editable in the portal itself. 

  • Darien

    Zendesk you had one job!!! 

    How is this basic feature request not fulfilled after 5 years of user requests is beyond reason. This is completely unacceptable! 
    Our end-users are unable to even alter the subject of the tickets they file.

  • Johanne Leveille-Schirm

    We have the same request - I actually was surprise today when I tested this and realized that end user could not edit the Subject field - which they provided in the first place. They should be able to edit all fields (except for previously submitted comments) that they were asked to complete.

  • Zach Johnson

    +1 Why can't end-users update ticket fields if a field needs to be changed? Obviously this should be configurable (editable/not editable) when the ticket field is created.

  • lphrr

    Has anyone learned of an alternative?

  • Sonja London

    Has this been addressed by Zendesk ?  Hard to believe this is not an option!

  • Dave Gordon

    How can we raise visibility of this request? Are any moderators watching this thread who can help us get this prioritized? We have a need for this, which has been requested by a strategic customer of ours. Thanks.

  • Radoslaw Hofman

    Hey, any decision if it will be implemented or ETA?

  • Nicole Saunders
    Zendesk Community Manager

    Thanks for the detailed feedback, David.

    We're continuing to collect use-cases and votes, as the Support product team is looking into improvements to the ticketing workflow.

  • James Pitcher

    +1 on this, simply I would like the option on each field whether the customer can edit this field once the ticket has been logged, this will allow the customer to edit the subject, or raise/lower the priority.

  • Serge Payette

    Hi Donna,

      Ditto here, I looked again and again and - unfortunately - that feature doesn't exist with Zendesk Plus license.

  • Carl Giardina

    I've noticed this same request raised in multiple threads dating back to 2013. It would seem to me that allowing users to edit/update ticket fields should be part of the standard architecture.


    We have a ticket flow that requires 2 user engagements, and it's disappointing learn that we'll have to setup multiple forms and track and consolidate at least 2 tickets for each user request;


    Has anyone learned of an alternative?

  • Dan Duncan

    Yes, I agree.  I am particularly interested in the Subject field.  We may have a customer who wants to edit the subject but they have no way of doing this themselves.  

  • Brandon Peck

    We have the same need. There are additional pieces of discrete information we need our End Users to provided incrementally as we work through resolving a ticket. As others mention above, we also have many cases where our End Users would like to change or append fields from the initial submission (and their doing so would help drive the correct workflows and notifications on our end). Not being able to update those discrete fields after submission prevents us from measuring some key metrics; results in tickets not being able to be routed to the correct "workflow", notifications, and triggers; as well as adds overhead to our Agents when they need to update the discrete fields based on information provided by our End Users through comments.

  • Matthew Benn

    Has anyone figured out a workaround? I've searched the internet, ZenDesk App Marketplace, Zapier, and the Community here, so far there does not seem to be a way to do this. 

  • Dave Gordon

    Hi Nicole,

    Thanks for the response. I assume you folks have a system for tracking Enhancement Requests. Can you tel me if this is already in that system? If not, can you add it please, so that it is visible at some level? 

    Regarding impact, we have customers who would like to add additional team members to CC from within the Support Portal, which is not allowed after the ticket is submitted. They also would like to modify the Priority, which would then allow us to set up an escalation trigger. Lastly, they would like to modify certain other fields for their own tracking and reporting purposes, which again is not possible.

    Impact: Workflow improvements will help us scale our support services, and without knowledge that some of our concerns will be addressed, we will likely need to investigate alternatives to see if we can better meet our customers' needs long term.

    Thanks for your attention.


  • Peter Rifkind

    Any word on this feature request?  Is there an alternate workflow that anyone can suggest?

  • Eric Husband

    We would also like the ability to be able to allow our End users to Escalate and change the priority of Tickets themselves.


    This seems like a very basic feature that should be table stakes for a CRM.

  • Alejandro Colon


    Now I am even more interested. 

    Are you displaying something on the help center that allows the user to change the information?

    Or is this on a custom-built form?


    I am interested because I am trying to get away from email submissions but there will always be those who want to do it that way. So, I wondered if there was a way to update a ticket from Zendesk HC. Of course there is not. Then I took a few hours and created a proof of concept of sending any email ticket request a response that auto-generates essentially a form that they can fill out and update the ticket. I plan on telling requesters that email their ticket in that we will not look at it until all of the information is added.

    The reason I did it that way was that there is no way for an end-user to update a ticket from HC. 

    I ended up creating a simple endpoint that I maintain to do this. In the same way, the request gets sent to my endpoint. But, I was not sure how I would go about it on the actual HC. Like adding options or something to the form they see in HC.

  • David Windell

    Using some custom Javascript in a custom HC theme we added this which calls our remote API:

  • Alejandro Colon


    That is exactly what I was looking for. 


    I think that would be a great tip to add to the community if your company would allow that. I really think a lot of Admins would be interested if you were to do so. 

    If you don't want to go through the trouble but don't mind sharing the code you used, I would not mind writing it up for you. 

  • Paolo Gaioni

    @... Can you share the Javascript you are using?

  • Christopher Reichle

    We have custom fields on our ticket that the user can select and edit when submitting a ticket through the portal but after that, they are unable to change these fields. The portal from the end user's standpoint is a useless interface. Why can't they edit fields that I have setup as editable by the end user?

    I don't expect to see ZD do anything about this. They really don't listen or address these valid concerns that their loyal base submit. Comments go on for 10 years and nothing. I'm looking at the possibility of switching to something else with a more responsive development team. There are just so many basic functions you assume would be in this product only to find that not only are they not there but ZD has known for years that people want/need it and do nothing.

    It has been 3 years. How long does it take development to give a thumbs up or down on this so we can just concede defeat and move on to another product?

  • Jaclyn Ruby

    Agree with all of the sentiments above. Sometimes our end-users need to update the priority of a ticket or need to update a field after the ticket has been submitted. 

    To make Zendesk truly "real-time" and interactive this feature is very important. 

  • Brad Harris

    @... - I would love know how you were able to pull this off as well!


Please sign in to leave a comment.

Powered by Zendesk