Comments

26 comments

  • Avatar
    Vi Nguyen

    What do we mean by the following?

    "If a ticket's status is set to Pending or Solved, and requester performs an update, status is changed back to Open."

    Once it is marked solved but someone performs what kind of 'update' that will trigger status change back to 'Open'?  Commenting?  Changing something else?  Please confirm what we mean by update.  Thanks so much.

  • Avatar
    Kevin Kelly

    Up until a few weeks ago, we had an escalation trigger that changed a ticket's group assignment from one group to another. It used to work even if an agent was assigned already. Now it's stopped working and no combination of triggers or automations that I can think of will force the group to change. This is seriously breaking our ability to escalate tickets from one group to another. The only thing I can think of is these inborn ticket rules. Can this please be fixed? I can think of a lot of better uses of my time than me sitting there (as  and administrator) manually changing tickets from one group to another.

  • Avatar
    Evan Smith

    @Kevin -- agreed.

    Our Customer Support group opens a ticket, but has to escalate to Development for something. When Dev is done with it, it seems like the preferred path is to assign it back to Support so they can verify that the ticket has actually been addressed to the customer's satisfaction. Then Support would mark the ticket as solved. This is our primary use case, as Dev uses Pivotal Tracker integration, and doesn't log into ZD.

    Is the only way to address this scenario for Dev to mark the ticket as solved? Are there any other options?

  • Avatar
    Catrin Gärdlund

    Have something changed regarding the "If a ticket's status is set to Pending or Solved, and requester performs an update, status is changed back to Open." Our Pending tickets have stopped autoopen on answer from the requester which causes problems for us when prioritizing which tickets to focus on. Now we need to check both statuses to cover things.

  • Avatar
    Stuart Corcoran

    Since "requester" and "end user" can be different I think it is important, at least is was to me, to make a small correction.

    This

    "If a ticket's status is set to Pending or Solved, and *requester *performs an update, status is changed back to Open."

    would be more accurate as

    "If a ticket's status is set to Pending or Solved, and end user performs an update, status is changed back to Open."

    This covers the case where an end user on the cc of the ticket, not the requester, replies.  This will also re-Open the ticket.

  • Avatar
    Intekhab Hussain

    It looks like when:

    • the status of the ticket is Solved
    • clients replies from email

    The ticket status still stays Solved rather than turning back to Open?

    Is this how the desk works or am I missing something?

    To overcome with it, I have created a custom Trigger as:

    • Status is Solved
    • Ticket is Updated

    Perform: set Status to Open

    Is that the way I do it?

  • Avatar
    Forest

    Hi Intekhab, If a ticket's status is set to Solved and the requester sends an update, the status should change back to Open. Are your users signing into your help desk or are they responding via email? If they are logging in, they may be selecting 'Please consider this request as resolved' when they submit their update.

  • Avatar
    Intekhab Hussain

    No, it was a reply from email. Basically I am setting up my desk, so it was a test reply from another email account by myself.

  • Avatar
    Intekhab Hussain

    Sorry! My fault.

    It must be some other (faulty) custom trigger/automation rule that set the ticket reply back to solved. I test the issue again immediately after client submission and it does set the status back to open.

  • Avatar
    Fabian Mellenthin

    Plus an agent cannot set the ticket to another group if he is not member of that group he wants to assign the ticket to. I need a workaround for that too, please. Thanks

  • Avatar
    community engine

    Does this list need to be updated/refreshed? Its over 3.5 years old.

  • Avatar
    Aaron Pewtherer

    @CommEng Nope. Still good after all these years. . .

  • Avatar
    abdullah f

    t230150

  • Avatar
    Aaron Pewtherer

    @Abdullah: What does "t230150" mean? ;)

  • Avatar
    Amy

    It makes sense that the ticket changes to Open status from New when it gets assigned to an agent. That part is ok, but what gives me trouble is the 'Updater' field gets changed from 'User' to 'Agent'. I use the Updater field to see if my clients have answered and if the ticket is waiting for me or for them. Is there a way to leave that set as User until an agent actually puts some type of change on the ticket (other than just assigning it to someone)?

  • Avatar
    Aaron Pewtherer

    @Amy: In a View, use the "Requester update" and sort by that field, or use the "Pending" ticket type if you are waiting on the enduser tor reply.

  • Avatar
    Amy

    I don't follow how that can help me if it shows Agent when I have not yet tended to the case.

    It's a brand new ticket that my boss assigned to me, but shows Agent as last responder in the ticket. I have no way to see my new tickets vs my already existent tickets.

  • Avatar
    Aaron Pewtherer

    @Amy: Correct. Now edit your View, and add the column "Latest update by requester" and add that to the "Group By: Latest update by requester." Screenshot on View edit attached. Sort_by_Requester_Update.jpg

  • Avatar
    Amy

    Thanks for trying, but I set it up that way and it does not solve the problem.

    I still have tickets I've responded to listed first and tickets that are waiting for my response below and mixed in. I still have to read each one to see if I need to do something.

  • Avatar
    Aaron Pewtherer

    @iconky888: Did you mean to post here?

    @Amy: Trying grouping by requester type enduser/agent. See below:

    Lastest_Updater_Type.jpg

  • Avatar
    Iliya Yordanov

    These rules make no sense... I get this:

    "Assignee cannot be reset within group"

    I saw your explanation but it still makes no sense and makes me want to ditch ZenDesk because this and many other things just make it un-usable to me and my company. Guys, consider loosing things up a little bit...

  • Avatar
    Justin

    Hi Iliya: 

    Preventing the assignee from being reset within the same group inhibits the agent from simply sending the ticket back to the queue of he/she doesn't want to address the issue. Essentially, the ticket would have the potential to be unassigned and assigned endlessly. It would be difficult to establish accountability for those issues. And, floating tickets can skew reporting data as well. 

    If you have comments or feedback on other aspects of Zendesk, I'd be happy to follow-up and discuss in a ticket. Just let me know! 

  • Avatar
    Aaron Pewtherer

    @IIya: Not allowing a ticket to be reset within a group is an industry-standard approach (ITIL) to restrict the ability of tickets to be endless recycled by agents. As a workaround, you can add a ticket field (eg. checkbox) that uses a trigger to reset the group when checked.

    The trigger would look like this:

    Condition1: Ticket is...updated
    Condition2: [Checkbox]...Yes 

    Action1: Assignee...- 
    Action2: Checkbox...No 

  • Avatar
    Baptiste CANDELIER

    Is this list still true for Zendesk 2015?

  • Avatar
    Jessie Schutz

    Hi Baptiste!

    All of these items are still correct!

    Please let me know if you have any other questions!

Please sign in to leave a comment.

Powered by Zendesk