Multiple reports & outages

Tick the rows in the ticket list and click “Multiple report”. The button becomes usable from two ticked rows onwards.

The dialog asks first: “Which ticket stays?” The oldest ticket is preselected, so the deadline runs from the requester’s first contact instead of their second attempt. You can pick a different one.

Below it stands the direction with both numbers: “#11 will be closed and moved into #10.” So before the click it is clear which ticket stays.

Everything comes along: comments, attachments and the description of the second report. The description becomes a comment on the original, with its original author and its date. The dialog states the numbers beforehand.

Recorded time is moved, not copied. Otherwise the same effort would sit on two tickets and be billed twice.

The second report is not deleted. It is closed and points to the original from then on, and its number stays valid.

The requester does not get a separate e-mail. They are on the original and see everything there. The closed report carries a comment naming the original, which they can read.

There is no undo. That is why everything stands in the dialog before you click “Merge”.

Afterwards the history of both tickets records who merged what and when.

The requester has the old ticket number in their mailbox. They know nothing about two reports having been merged and reply to the mail they have.

That reply lands in the original. The system follows the reference the closed report carries.

That is why a merged report is never deleted. Without it the reference would not exist and the reply would arrive nowhere.

Whoever took part in the old report may also write on the original. The check happens on the ticket named in the mail.

If you select tickets from different people, the dialog does not take them along. It names every rejected row and its reason before you click.

The reason reads: “Different requester — this is an incident, not a multiple report.” It also tells you where to go instead.

This is the most important guard of the whole function. If you merged thirty reports from thirty people, twenty-nine of them would lose their ticket and never hear back.

Who the requester is is decided first by the e-mail address on the ticket. If there is none, a foreign name in the “User” field decides, and the same name counts as the same person. Otherwise the account that created the ticket counts.

This is why the guard also holds for phone calls. If an agent records two calls, both tickets were created by them. Different callers still stay different callers, because their names are in the field.

If the requester cannot be determined on one side, it is rejected as well. Unknown is not the same as the same person.

More reasons appear in the same box. An incident cannot be merged. A closed original takes nothing more. And a report that already has reports of its own does not come along, so no chains are formed.

When the file server goes down, twenty people report it. Every one of these reports is a case of its own with its own requester. Merging would be wrong here, because nineteen people would lose their ticket.

Tick the reports and click “Group into incident”. The dialog offers three routes: add them to an incident that is already open, declare one of the selected tickets to be the incident, or create a new incident with its own title.

If the team already has an open incident, that route is preselected. It is the more common one: the outage is long known, only new reports keep coming in.

Every linked ticket keeps its requester, its status and its own deadline. Nothing disappears. The incident only bundles the answer.

All reports of one incident have to belong to the same team. If an outage affects two teams, each gets its own incident. Otherwise one team’s resolution would empty the other team’s queue.

You can also attach latecomers on the single ticket. If the team has an open incident, a hint appears at the top with “Assign” and “Not related”. The system never attaches anything by itself: a wrongly attached ticket would get a resolution that does not concern it, and would be closed along the way.

The incident ticket states how many reports are attached to it. Linked tickets in turn carry the number of their incident, in the list and in the card on the right.

“Resolve incident” closes the incident and answers all reports at once. The resolution text is mandatory: it is the entire point of the function, because it goes to everyone affected.

Every linked ticket gets the text as a public comment, is set to the chosen status, and its requester receives their own e-mail. No group mail, because that would expose the addresses of everyone affected.

The message afterwards states how many tickets were closed and how many requesters were notified. Both numbers stand apart, because a ticket without a reachable address gets a comment and a status but no e-mail.

A ticket you answered and closed yourself in the meantime stays untouched. It is not closed a second time and not written to again.

As long as open reports hang on an incident, it cannot be closed through the normal status change. Otherwise twenty people would silently be left without an answer.

The dialog and the incident ticket both carry the checkbox “Also show as a banner on the sign-in page”. With it everyone learns about the outage before writing another ticket.

The banner stands on the sign-in page and inside the system once signed in. It names “Known incident” and the title of the incident, so that title is a text for customers.

If several notices are active, they stand below one another. Maintenance announced for Saturday does not push away today’s outage, and the other way round.

If somebody creates a new ticket anyway, the automatic reply names the incident. That holds for a ticket that is already linked and for every new ticket of that team, as long as the incident is open and announced. This needs outgoing e-mail.

Once the incident is resolved the banner disappears by itself. Nobody has to remember to switch it off again.

On the “Maintenance and incident notices” page you can see which incident is running as a banner right now. The switch on that page belongs to planned maintenance and does not apply to incidents.