Forums/Community/Community tips & tricks

Inborn Ticket Rules

Mikkel Svane
posted this on April 04, 2008 03:48

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. 
 

Comments

User photo
Vi Nguyen
getaroom

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.

May 13, 2010 11:46
User photo
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.

June 29, 2010 23:20
User photo
Evan Smith
n2uitive

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

October 20, 2010 08:31
User photo
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.

December 16, 2010 07:12
User photo
Stuart Corcoran
mercent

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.

February 03, 2011 13:28
User photo
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?

March 29, 2011 09:27
User photo
Forest
Zendesk for iPad Beta

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.

March 29, 2011 09:32
User photo
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.

March 29, 2011 09:36
User photo
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.

March 30, 2011 10:02
User photo
Fabian Mellenthin
Groupon EMEA

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

May 26, 2011 02:37
User photo
community engine

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

December 13, 2011 16:22
User photo
Aaron Pewtherer
Zendesk

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

December 23, 2011 15:53
User photo
abdullah f
t230150
May 25, 2012 05:17
User photo
Aaron Pewtherer
Zendesk

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

May 25, 2012 09:05
User photo
Amy
realtech

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

June 29, 2012 06:50
User photo
Aaron Pewtherer
Zendesk

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

June 29, 2012 13:26
User photo
Amy
realtech

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.

June 29, 2012 13:58
User photo
Aaron Pewtherer
Zendesk

@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

June 29, 2012 14:06
User photo
Amy
realtech

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.

July 05, 2012 05:51
User photo
Aaron Pewtherer
Zendesk

@iconky888: Did you mean to post here?

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

Lastest_Updater_Type.jpg

July 05, 2012 09:51
User photo
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...

October 19, 2012 16:16
User photo
Justin Seymour
Zendesk

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! 

October 22, 2012 07:46
User photo
Aaron Pewtherer
Zendesk

@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 

October 23, 2012 11:09