31

Inborn Ticket Rules

Some business rules in Zendesk are inborn, meaning that they cannot be reconfigured and makes part of a help desk's modus operandi:

  • When a ticket is assigned to an agent, the ticket status automatically changes Open. You'll see the change after you update the ticket.
  • Once a ticket's status has been changed from New, it can never be set back to New.
  • If a ticket's status is set to Pending or Solved, and the ticket requester updates it:

    • If the ticket requester is an end-user, the status is automatically changed back to Open.
  • If the ticket requester is an agent, the status is not automatically changed.

  • A ticket's status cannot be set to Solved without an assignee.

  • Once a ticket has been assigned to a group, it cannot be reset to no group. You can however change it to a different group.

  • Likewise, once a ticket has been assigned to an agent in a group, you cannot reset the assignee to no one. You can of course assign it to another agent.

  • Once you set a priority, you cannot reset it back to no priority. You can always change it to a different priority.

  • When a ticket's status has been set to Closed, it can never be updated, it can only be deleted. The requester can however create a follow-up request that references the closed ticket.

  • If there's only one group in the help desk, all tickets are automatically assigned to that group.

  • If there's only one agent in a group, all tickets assigned to that group are automatically assigned to that agent.

  • You cannot assign a ticket to an agent without first assigning it to a group.

26 comments

  • 0

    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.

  • 0

    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.

  • 0

    @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?

  • 0

    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.

  • 0

    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.

  • 0

    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?

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

  • 0

    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.

  • 0

    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.

  • 0

    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

  • 0

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

  • 0

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

  • 0

    t230150

  • 0

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

  • 0

    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)?

  • 0

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

  • 0

    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.

  • 0

    @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

  • 0

    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.

  • 0

    @iconky888: Did you mean to post here?

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

    Lastest_Updater_Type.jpg

  • 0

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

  • 0

    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! 

  • 0

    @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 

  • 0

    Is this list still true for Zendesk 2015?

  • 0

    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.