Problem-and-incident tickets are useful when a problem or service interruption is reported by more than one person. For example, when the wireless network in an office stops working, several people might file tickets. You can treat the tickets as incident reports. Instead of handling each ticket separately, you can link the tickets to one problem ticket, and then solve the problem ticket to solve all the incident tickets.
Here's the general workflow:
- Identify a service interruption or problem that's causing people to file tickets.
- Create your own ticket to address the problem.
- Change the other tickets to incident tickets and link them to your problem ticket.
- Solve the problem ticket.
When you solve the problem ticket, the status of all the incident tickets is automatically set to solved. The comment added to the problem ticket when solved will be added to all incident tickets that are not yet closed.
Refrain from solving any of the incident tickets directly. Solving an incident ticket still leaves the other tickets unsolved. Save work by solving only the problem ticket. It automatically solves all the linked incident tickets. When the problem ticket is solved, any empty required fields on linked incident tickets are ignored and tickets are solved anyway.
To create problem-and-incident tickets
- After identifying a problem that's causing people to file tickets, create your own ticket describing the problem and set the ticket type to Problem.
- For every other ticket reporting the same problem, set the ticket type to Incident and link it to the problem ticket.
After you set the type to Incident, a second menu appears that lets you link the incident to a problem ticket.
Make sure to click Update to save the changes to the ticket.
- Solve the problem ticket.
The problem ticket has a link to a view of linked tickets so you can review the incident reports.
Solving the problem ticket solves all the incident tickets linked to it. Only the comment added when solving the problem ticket will be included in all linked incident tickets.
Tip: Use dynamic content placeholders to personalize the comment for wide distribution. Example:
For more information, see Using placeholders.
If you decide to reopen the solved problem ticket, the incident tickets aren't updated. They stay solved. If you solved a problem ticket prematurely or if you need to communicate something more to the requesters, you can easily reopen the incident tickets before solving the problem ticket again. Click the Incidents tab when viewing the problem ticket and bulk edit all of the tickets. Submit the tickets as open and proceed with re-solving the problem ticket.
Related topics
85 Comments
Leander
I would suggest it is safer to create a separate problem ticket. That keeps all your customer facing tickets as incidents. When you look at the incident tab, you are being consistent and all the customer incidents are listed there. There is nothing special about the fist customer that raises the ticket, so you do not want to be processing that ticket differently from all the other incidents.
Having a separate problem ticket also allows you to make notes and reassignments without the risk of the customer being accidentally updated or notified of comments that may confuse them. It also gives you the option of different business rules and notifications for problem tickets. Again, you may want to keep these notifications internal.
The risk of accidentally looping in the first customer can be higher if you CC users into the problem ticket.
If you have Insights and are concerned about duplicate tickets, you can exclude the problem ticket types from your counts.
You can of course keep the problem ticket as the first ticket, but keeping it separate gives more options.
Am I the only one that needs to be able to report out on not just the total number of incidents linked to a problem ticket but also their statuses? In a perfect world, we would solve the problem ticket and have it cascade down but our business process is that we check with each customer that our workaround and perm fix went in as expected, leaving us with some solved incidents, some pending incidents and some open incidents. We need to be able to easily report to managers what the current status is. I can't seem to create a view for this. And there's no way to sort the incidents by status.
Am I missing something?
Hi Heather!
I did some testing in my own Zendesk was able to create a View that will show these tickets, so you should definitely be able to do this as well. I've included some screenshots of how I built it.
Here, you can see where I specified the ticket type, and which statuses should be shown:
Here, I've grouped the tickets by status so they'll automatically be sorted, and then set so they're listed in order of what was most recently updated. Of course, you can adjust that part however you'd like.
And here is what it'll look like in action.
Let me know if you have any questions or problems!
Hi Jesse, That's really helpful except it shows all incidents. I'm looking for a way to view all incidents linked to a particular Problem ticket. So, if we cannot reorder the list of Incidents when we are looking at the Problem ticket, I'm stuck with looking for a solution through creating a view. The view you did is wonderful but it lacks the ability to identify
1) if it's linked to a problem ticket
2) if linked to a problem ticket, what is the problem ticket number
Otherwise, your view is essentially a list of all unsolved incident tickets which unfortunately doesn't narrow it down for us!
Any other ideas?
Hey Heather! Apologies if I misunderstood your initial question!
I would say that your best bet would be to create a custom field that contains the problem ticket number, and then add that custom field to your view. Then you'll be able to either create a view for each problem ticket, or just sort by that field in your normal view.
I know it's a pretty manual solution, but it sounds like you link all your tickets to problem tickets so it would be pretty easy to set up macros your agents can use to ensure that the field is populated correctly. It'd just need to be a drop-down field, rather than free-text.
Sorry - this may have already been covered, but say you had a problem/root cause ticket (created by us), but we have a workaround in place - those tickets are incidents that get raised and solved as they come in.
If we link those incident tickets to the problem ticket (to track impact), when it eventually gets solved by our Development Team, all the incidents linked to it (now closed), do they all get reopened? Or would the linked incidents only get updated when the comment/status of the problem ticket if they are still open?
Hey Dave! Welcome to the Community, and thanks for the head-scratcher!
I can say for certain that if you update that Problem ticket with an internal comment, nothing will happen with the Solved Incidents.
Outside of that, I'll need to do some testing on my end to see how this would work in action. I'll let you know what I figure out!
Hi Dave, just following up here.
I tested this in my own instance with a Problem ticket that had a Solved incident, a Closed incident, and an On-Hold incident linked to it. I Solved the Problem ticket with a public comment; here's what happened:
The Solved ticket was not updated. The ticket status was not changed. No public comment was added. No email notification was sent.
Closed tickets can't be modified in any way, so in this case I was testing for a Follow-up ticket. A Follow-up ticket was not created. No email notification was sent.
The On-hold ticket was updated as expected, and an email notification was sent.
Based on this test, it looks like Solved or Closed incident tickets will not be re-opened and updated, nor will they generate any notification to the end-user.
However, I would strongly recommend testing this in your production instance to make sure it behaves the same way for you. I did this testing with no custom fields, and only one custom trigger (which was used to immediately close one of the incidents for testing, prior to solving thre problem ticket). Depending on your set up your mileage may vary.
Let me know if you have any other questions!
This is really useful Jessie, thankyou very much for investigating! As suggested I'll check this on our own environment, but if successful it means we can do a lot more with tracking repeat incidents.
Thanks again!
Dave.
Hi,
Something I have been trying to do lately is see whether when you solve a problem ticket, tags get propagated to the incident tickets and I have found it is not the case.
Is it that the case? Am I missing something?
Best,
Ramon
Why can't we just link incident tickets to other incidents, and be able to show the link within each ticket? Thats low hanging fruit that Zendesk has never been able to implement. See Atlassian JIRA functionality regarding what I'm talking about.
Hey Jimmy -
I'm not sure I understand what you mean. Can you give an example of your use case?
Hi Ramon!
You're correct: when you solve a Problem ticket, the public comment is inherited and the status of each incident is changed to Solved, but no other ticket attributes are inherited. Is there a particular workflow you're trying to accomplish?
How to ensure that Incident tickets are not solved without linking to a Problem? Is there a report I can create in Insights to find out the Incident tickets without a Problem linked to them?
Another thing. I want to bifurcate the Problem tickets into two:
I cannot figure out how to do this in Insights. Can someone help?
Hi Aswin!
We'll need to see about getting an Insights expert in here to see how to report on that information. I'll try to get someone in here ASAP.
As far as making sure an Incident isn't solved without being attached to a Problem...you could create a trigger that adds an "incident" tag when a ticket type is updated to Incident, and then a second trigger that tests for that tag and re-opens the ticket when it's set to Solved when the tag is present. When the ticket is re-opened, you could add a private note remind the agent to select a Problem from the list and change the status to On-hold, or change the ticket type if it's not actually an Incident.
There are a couple sticky parts to this though. Firstly, there's no way for a trigger to actually test for whether a Problem ticket has been selected from the dropdown on an Incident. Secondly, you'd need to figure out how and when to remove the "incident" tag so it doesn't get re-opened when the Incident is solved with the Problem ticket. You'll want to take that into consideration...it might require some macros and custom fields.
Hi Aswin,
The simplest way I can think of to show Problems with Incidents and Problems without would be to build the following report:
What:
# Incidents
How:
Ticket Problem
Filter:
Ticket Type | Is | Problem, Incident
Then sort the # Incidents column to show the highest value at the top. This would include all problems, but at some point in the report the # incidents would change to 0. If you needed a clear divide, you could create two reports and on the second add to your filter a numeric filter that is set to look at Ticket Problems where the # Incidents is equal to 0.
Hi Daniel - I have tried that, but I cannot do it channel-wise. I've found another workaround by adding tags and triggers, and now I'm reporting using tags. It works as expected, but still I think it'd be easier do to this via Zendesk Insights.
For Incidents that are Solved without a Problem ticket, I'm running a report everyday and talking to the agents to eradicate that practice gradually.
You could potentially add Ticket via under How to give you the channel (assuming you just mean web, email, api, etc).
Gurunn
Rather than click the down arrow, you need to click on the Edit X ticket(s) part:
To be fair, if you have more than 30 incidents, you'll need to select and edit all on each screen of 30 incidents. Next page, next page, next page....
Thanks for the clarification Graeme. I just figured it out after I had posted the comment :)
Hi,
I would like to ask how should we combine our usage of Incidents & Problems, with our SLA policies?
Let's say, for example, that we have SLA set up with a certain maximum time between replies.
When we link an incident to a problem ticket, my assumption is that we're expected to work on the Problem ticket from that point on. Posting comments, updates, and so on.
But other than the eventual solving of the Problem ticket, nothing is propagated to the linked incidents. So, as a result, these incident tickets breach their SLA (because they're not being updated - the Problem tickets are being updated instead).
I hoped that there's a way to make SLA ignore incident tickets that were linked to a problem, but unfortunately, I found no way to add such a filter.
Not as a trigger either. I couldn't find any built-in automated way to identify whether an incident ticket is linked to a problem or not.
Closest thing we could do at this point is add a Macro that adds a tag to the incident ticket, which then the SLA filter can ignore. But this hardly feels like the right way to go about this.
Is there a better / more correct way to make this work?
Thanks
Hey, Eitan!
I hope all is well.
You can work on Incident tickets that are linked from within the Problem ticket itself! To access this area, click on the Incidents tab in the Problem ticket:
This will allow you to make updates to those tickets while updating your SLAs to not breach (or add tags so the SLA is ignored). You can even update the entire list as bulk!
This should help with locating incidents and avoiding SLA breaches. I hope you find it useful!
Hello,
Would this work in the instance of having our Level 2 support creating a problem ticket then allowing all Level 1 agents that receive calls to that Problem ticket. Then once the issue is resolved and the Level 2 agents send an email closing out the problem ticket and the level 1 agents dont have to touch it after that? Or does it work on a person by person basis? We also would not want our Level 1 reps creating a Problem ticket. Only Team Leads and Level 2 Care employees. I appreciate the help.
Hello Samer,
Yes, you could have the Problem Ticket be solved by the Level 2 agent and all incidents, that may be held by Level 1 agents, connected to the Problem ticket will close out with one last update from the Problem Ticket.
With this workflow, your Level 1 agents can still update the requesters as necessary, and work the incidents as would be required,
Hi folks,
I was wondering if it was possible to copy custom fields (or apply some tags) to all incidents linked with a problem upon solving the problem?
I was a sub-status custom field and when I solve a problem with incidents attached, I'd like the same custom field to be applied to all the attached incidents. Is that possible?
Hi Jaïs!
I would think you'd be able to do this with a trigger. Setting it up with conditions of Type > is > Incident and Status > changed to > Solved and then indicating what the custom fields should be in the action section should get you where you need to go.
Hi Jessie, thanks for your answer, but I don't think it works.
If I do this, the trigger will SET the custom field to a defined value not based on the parent problem value.
Writing several triggers would not work either for there doesn't seem to be a condition where I can access the custom field value of the parent problem for an incident.
Do you see what I mean?
Hi Jaïs,
Thanks for the clarification! As it turns out, there's no way to set ticket fields based off ticket fields set within another ticket on your account. This includes incidents attached to problem tickets. These fields would need to be manually set by the agents on the account or through a trigger based on conditions within that particular ticket.
Let us know if you have any other questions for us!
Please sign in to leave a comment.