Updating and solving tickets

Have more questions? Submit a request

39 Comments

  • Juergen Wagenbach
    Comment actions Permalink

    Dear Brett

    I have tested a lot and it worked ;-)

    I just had some other problem then because we assign the ticket to an agent if a agent replies and it was not assigned before. I had to adapt this trigger too.

    Anyway I think that this trigger was nonsense any way before and could be deactivated without any drawback.

    I implemented the same for "Pending" tickets. Otherwise the ticket swapped to "Pending" but to "Open" immediately again. I kept the first three "Add" conditions the same but I ha to exchange the last "Add" condition ("Assignee is not (current user)") to the following:
    Requester is (current user).

    Everything seems to work now perfect based on some extensive tests.

    0
  • Brett - Community Manager
    Comment actions Permalink

    Happy to help Juergen :)

    Super appreciate you taking the time to post a detailed fix to your issue.

    Thanks again!

    0
  • Mohamed Fouad
    Comment actions Permalink

    Hi,

     

    When am replying to a ticket, it's not being sent to the customer,, any idea why?

    1
  • Brett - Community Manager
    Comment actions Permalink

    Hi Mohamed,

    You'll want to check the ticket events of your ticket to confirm whether or not the appropriate trigger is firing. You should have a Notify requester of received request and Notify requester of comment update trigger by default that sends your reply to the customer. More on default triggers here: About Support default triggers

    I hope this helps!

    0
  • Sean Cox
    Comment actions Permalink

    Is there a way to limit what users/groups can edit a field within a ticket or set it up so that only certain types of tickets can only be "Solved" by a manager? For example, the level 1 support agent does the work, but the manager needs to approve before the case can be Solved. I can set up the triggers and approval notifications, but I can't figure out how to not allow the level 1 agent from checking the required "Approved" checkbox I've set up and then move the status to Solved. I know I could still set up a trigger to notify the manager if they do that, but if possible I'd prefer to not allow them to move the status to Solved without explicitly getting manager approval.

    0
  • Dan Ross
    Comment actions Permalink

    Hey Sean,

    No native field restrictions available unfortunately.

    There's a few apps in the Marketplace that handle approval based workflows. I believe one was called Myndbend, and there's one called Approvals by Sweethawk but there's a few others. We use some other Sweethawk apps and have been very happy with them. (I don't work for them, just a happy customer).

     

    If that's not an option you might be able to make something workable using trigger based flows around tags, but there's likely room for unscrupulous agents to exploit them. They'd also be subject to more maintenance as people join and leave the team.

    Hope that helps.

    0
  • Dan Cooper
    Comment actions Permalink

    Hi Sean, 

    If your managers are your Admins, you could potentially use the Tag Locker application to set a certain tag that can only be used by managers and have a trigger that re-opens a ticket if that tag is not present.

    Alternatively, there are several other apps that allow for an approval workflow.  Approvals or Myndbend Process Manager might give you some tools to help make sure tickets are completed appropriately - although I'm not sure if they'd actively block a ticket from being solved. 

    Alternatively, if you have a developer in house, you could build logic that would prevent someone from submitted the ticket if certain criteria didn't exist.  The Zendesk App Framework will let you disable the submit function based on your own logic if you've got the means to write your own app

    There is always the non-technical solution as well.  If this is a solution to a problem that is rare, it might be better to deal with the rarity through management process than to solve for it with tooling.  It's nice to save people from themselves, but training teams and trusting them goes a long way too. 

    Hopefully, one of these options will give you a path forward. 

    0
  • Jonathan March
    Comment actions Permalink

    Just off the top of the head, so apologies if I'm missing something, but I *think* you should be able to do it with a single trigger that tests for this particular kind of ticket, AND for ticket is updated, AND status greater than on-hold, AND current user is not manager1 AND current user is not manager2, etc, and performs action status = Open.

    0
  • Sean Cox
    Comment actions Permalink

    Thanks for the feedback. It seems like we will either need to use one of the apps, build our own app, or rethink how we want to coordinate our workflow process between Zendesk and our admin platform. Our plan was to use the solved status as the final API trigger to let our admin system know that all escalation has been completed. Reversing the status based on triggers would cause a whole host of issues within reopening a closed portion of the admin system. We can handle this through training and reversing out the accidental (or hopefully not intentional) Solved status as they happen, but prefer to just not allow it to happen.

    0

Please sign in to leave a comment.

Powered by Zendesk