Linking Incidents to Problem Tickets Automatically in Zendesk

This covers what the two types actually do, what we found on our own instance, and the one route that does automate the link.

What the types are for

A problem ticket represents the underlying fault. An incident ticket is one customer's report of that fault. Ten people writing in about the same outage is one problem and ten incidents.

The payoff is the cascade. Per Zendesk's documentation on problem and incident tickets, "when you solve the problem ticket, the status of all the incident tickets is automatically set to solved", and "the comment added to the problem ticket when solved is added to all incident tickets that aren't already solved."

That documentation also carries a warning worth repeating, because it is the one people trip over: "Refrain from solving any of the incident tickets directly. Solving an incident ticket still leaves the other tickets unsolved." Work the problem, not the reports.

What we found on our own instance

We went looking for how much of this was actually in use on our developer instance. The answer was none of it.

A hundred and sixty-five tickets typed incident, and nothing to attach them to. We then sampled twenty of those incidents and checked the field that carries the link: zero of twenty had a problem_id set.

So every incident on the instance is orphaned. The type had been set, presumably because it described the ticket accurately, and the cascade those tickets exist to enable could never fire. That is not a misconfiguration anyone would notice, because a labeled incident looks exactly like a linked one until the day you solve the problem and nothing happens.

The linking is manual, and Zendesk says so

The reason those 165 tickets are orphaned is that linking is a person's job. You open the incident, set its type, and a second menu appears letting you pick the problem ticket to attach it to.

Zendesk's own workflow guide for tracking problems and incidents recommends a view for open problems and a trigger to notify a group when one is raised, and for the link itself it says to "be advised and link any related tickets as incidents." The automation it offers covers noticing the problem. The linking stays with the agent.

It is worth being clear about the incentive there, because it explains why this has not changed. Automatic linking means deciding that two tickets describe the same fault, and a wrong guess merges a customer's unrelated problem into someone else's outage and then silently solves it on their behalf. The cost of a false positive is a customer told their issue is fixed when nobody looked at it. Zendesk has left the judgment with the human, which is the defensible call, and it does mean the feature only works as well as the discipline around it.

The route that does automate it

The link is a plain field on the ticket, and the API will set it. That is the part the interface does not advertise.

We tested it on the instance described above. Create a problem ticket, then PUT the incident with the problem's id:

PUT /api/v2/tickets/570.json
{"ticket": {"problem_id": 1028}}

The response came back with type=incident and problem_id=1028. We linked three incidents to one problem this way, then solved the problem and read the incidents back:

All three flipped, and the closing comment we put on the problem appeared verbatim as a public comment on each incident. The cascade works exactly as documented, and it fires on links made through the API, not just links made by hand.

That turns the orphaned-incident problem into an ordinary scripting job. Our Zendesk API guide covers authenticating the calls; the update itself is one field.

The trap we hit while testing

Our first attempt to solve the problem ticket returned a 422 rather than solving anything:

Plan Type: is required when solving a ticket
Issue Started On: is required when solving a ticket

Two fields on this instance are marked required-on-solve, and the API enforces them the same way the agent interface does. Nothing about the problem-and-incident feature is involved; the ticket simply cannot reach solved without them.

That matters here more than it usually would, because the whole point of the cascade is that solving one ticket solves many. A script that solves problem tickets in bulk will stop dead on the first one missing a required field, and the incidents behind it stay open while everything looks like it ran. Check the required fields on the form your problem tickets use before you automate anything that solves them.

Finding the orphans you already have

Before automating anything, it is worth knowing the size of the backlog. Two counts tell you most of it: how many tickets are typed incident, and how many are typed problem. If the first is large and the second is near zero, you have the situation we found.

The precise check is the problem_id field. An incident with a null problem_id is not attached to anything, whatever its type says. Reading that across your open incidents gives you the list to work through, and it is the same field you would then be setting.

Deciding which problem each orphan belongs to is the part that stays human, for the reason in the section above. What the API removes is the clicking, not the judgment.

Common questions

Does setting a ticket's type to Incident link it to anything? No. The type is a label. The link lives in the ticket's problem_id field, and on our instance 165 tickets were typed incident with none of the sampled ones carrying a problem_id.

What happens when I solve a problem ticket? Zendesk sets every linked incident to solved and copies the problem's closing comment onto each incident that was not already solved. We confirmed both behaviors on three linked incidents.

Should I solve incident tickets directly? No. Zendesk's documentation says to refrain from it, because solving one incident leaves the rest unsolved and you lose the cascade that made the linking worthwhile.

Can I link incidents to a problem automatically? Not through triggers, and Zendesk's own workflow guide does the linking by hand. You can set problem_id through the API, which we tested, so the mechanical step is automatable even though the decision is not.

Why did my bulk solve fail with a 422? Almost certainly a field marked required when solving. Ours reported two by name. The API enforces the same requirements as the agent interface, so a script solving problem tickets needs to supply them.

Can an incident exist without a problem? Yes, and that is exactly the failure mode. Zendesk does not require the link, so nothing stops an instance accumulating incidents that point at nothing.

Where an AI layer fits

The step that stays human is a matching problem: this new ticket describes the same fault as that existing one. That is recognizably the kind of judgment people now ask automation to make, so it is worth being precise about where the risk sits.

The cost of a wrong link here is unusually high. A mislinked incident does not sit there looking wrong; it gets silently solved when somebody resolves an unrelated outage, and the customer is told their problem is fixed. So the useful shape is an agent that surfaces the candidate problem and the evidence for it while a person keeps the decision, rather than one that writes problem_id on its own judgment.

Macha reads tickets in your Zendesk and can act inside them under the permissions you grant it. It fits teams who already run the problem-and-incident model and keep finding the link never got made during the rush that created the incidents. It fits poorly as an unsupervised linker, for the reason above, and we would rather say that than sell the cascade as something safe to hand over entirely. Our Zendesk integration page covers what it reads, and the triggers guide covers the notification side Zendesk does automate.

Count your orphaned incidents first. Start a free trial once you know how big the backlog is.