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 is added to all incident tickets that aren't already solved.
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 the 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 is included in linked incident tickets that aren't already solved.
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.
This functionality works fine for us. However, it doesn't seem that views or reports have any parameters to pull problem tickets that have linked incidents or incidents that are linked to a problem. Or any ability to report on how many linked incidents any given problem has. The only visibility into the association is at the individual ticket level. That added layer of insight is really important for us. Any plans on this for the future or other ways to solve for this other than custom API reports?
How can I make the "linked problem" field required? I don't want agents logging an incident without associating with a Problem. It doesn't show up as a field in Admin Centre because I guess technically it's a sub field which is only displayed when Incident is selected as ticket type.
I created a ticket on your behalf, we will get in touch via email.
Hello Zendesk Community!
How can we limit the incidents that are proposed before linking a ticket to an incident? We only want to see incidents within the brand of the ticket. Any recommendations?
I don't think there's a built-in way to do that, so for now I think it's going to need to be addressed via training your agents to verify the brand before assigning an incident to a problem ticket. But can you post your use case to our Feedback on the ticketing system (Support) topic, using this template to format your feedback?
Is it possible to have an INC ticket, when attached to the Problem ticket, duplicate the fields that are set by the Problem ticket?
Hi Jed Hollander,
We don't have a native option at the moment for incident tickets to copy the ticket fields of the problem ticket. You may use the API and placeholders to pass field values from one ticket to another, but it’s really manual. It can’t dynamically send a problem ticket’s fields to all incidents. We do have a 3rd party app in the Zendesk Marketplace that you can check out called Ticket Field Copier. Hope this helps!
It seems like your correspondence has come to the wrong place! You've reached Zendesk support, and it sounds like you're probably trying to reach someone who *uses* our software to provide support. We make software that companies use to give their customers a way to contact them, but we don't actually provide support for their product, just the channel for communication.
Unfortunately, we are unable to forward your email on so please try reaching them directly from their website!
Any updates on changing the view of incidents list? I could benefit of having other columns and grouping cases with custom fields as we do for the normal queue views.
Any issue I can track on this?
Sadly, this feature is not available yet. But I will be sure to mark this as Product Feedback so it can be reviewed by our Product teams. Thanks!
We just ran into a case in which we want to send periodic updates to the incident tickets straight from the problem ticket, but this isn't available as comments on the problem ticket are only pushed to incident tickets when solving problem tickets.
Will there be any functionality in the future which allows for periodic updates on problem tickets to be pushed to incident tickets?
Hi in future will tasks be able to be linked to problem tickets
I am working to integrate the problem function within our environment and utilise the full functions of problem tickets. At present, we are going to use incidents as a workaround but not all problems will need an incident to fix them - they may need a task - Whether it be a change task or KB Known error task.
I am looking at linking them all together to get greater functionality out of the software
Thanks for your article
Please sign in to leave a comment.