Incident management process
The IT Service Desk template associates certain requests with an incident workflow. We set up the workflow to complement the following incident management process. We recommend you start with this workflow and adapt it to your specific needs over time.
The ITIL incident management process, in brief:
- Service end users, monitoring systems, or internal IT members report interruptions.
- The service desk describes and logs the incident. They link together all reports related to the service interruption.
- The service desk records the date and time, reporter name, and a unique ID for the incident. Jira Service Desk does this automatically.
- A service desk agent labels the incidents with appropriate categorization. The team uses these categories during post-incident reviews and for reporting.
- A service desk agent prioritizes the incident based on impact and urgency.
- The team diagnoses the incident, the services effected, and possible solutions. Agents communicate with incident reporters to help complete this diagnosis.
- If needed, the service desk team escalates the incident to second-line support representatives. These are the people who works regularly on the effected systems.
- The service desk resolves the service interruption and verifies that the fix is successful. The resolution is fully documented for future reference.
- The service desk closes the incident.
Team members should carry out post-incident reviews for major incidents. These investigations can help determine:
- missing requirements
- potential changes to service level agreements
- potential service improvements or focus areas
Jira Service Desk's default incident workflow
Using request types, you can associate incident reports with an issue type called Incident. This puts the incident record into our recommended incident workflow.
The workflow follows the basic process above. You can customize it to adapt to the needs of your business.
Customize your incident workflow
- Go to Project settings > Workflows.
- Select the edit icon (a pencil), in the entry titled Incident Management workflow for Jira Service Desk.
- Use the workflow editor to add or remove steps and transitions.
Auto-close incidents after resolving them
The IT Service Desk template includes an extra SLA and automation rule. Together, these automatically close incidents three business days after an agent resolves them.
The SLA called Time to close after resolution starts a clock when the resolution field of a incident is set. This clock stops if the an agent clears the resolution field or if the request transitions to Closed. You can view, edit or remove this SLA. Go to Project settings > SLAs. Read more about SLAs.
We include an automation rule called Auto-close after being resolved for 3 business days. This rule transitions an incident from Resolved to Closed when the above SLA breaches. You can disable or fine tune the rule. Go to Project settings > Automation to view or edit the rule. Read more about automation.
Link incident records to other issues
You can link issues together. For example, you can link incident records to a problem report or change request.
You can link issues in your service desk project to issues in other projects, or other Jira applications like Jira Software or Confluence.
For example, you might want to link an incident to Jira Software when a second or third line support member needs to work on a fix. Here's how that process might look:
When the cause of an incident is identified, second or third line support members create a task to fix it in Jira Software. Your service desk can leverage an automation rule to keep your customers updated on the fix.
To link the incident record to a fix task in another project:
- View the incident record.
- Click the more menu ().
- Select Link.
- In the This issue field, select is caused by.
- Enter the key for the issue you want to link to in the Issue field.
- Select Link.
Your service desk comes with an automation rule called Update when a linked issue changes. This rule comments on your incident record about the status of a linked Jira issue. So, when a development team progresses with their fix, your customers are kept up to date.
You can change or expand this rule to suit your needs. For example, you can close incidents automatically when development teams resolve issues in Jira. Or, you can send notifications to your customers when as development teams put fixes in place.
To edit your linked issue rules, go to Project settings > Automation and select Edit next to the rule called Update when a linked issue changes.
Default form fields for incident reports
Jira Service Desk allows you to customize the fields of information collected from customers. Additionally, you can customize the fields of information used by your agents. Jira Service Desk does this through issue type fields and screens. Fields help agents investigate, assess, and categorize the incident for reporting or querying.
By default, we include the following fields in your agents' view of an incident. If needed, you can add custom fields. Find out more about fields in Jira.
|Summary||A short description of the request.|
|Reporter||The person who submitted the request.|
|Component/s||Segments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labeling, categorization, and reporting.|
|Attachment||Files or images added to the request.|
|Description||A long, detailed description of the request.|
|Linked Issues||A list of other requests that affect or are effected by the request. If your business uses other Atlassian products, this list may include linked development issues.|
|Assignee||The team member assigned to work on the request.|
|Priority||The importance of the request's resolution, usually in regards to your business needs and goals. Sometimes, priority is calculated by impact and urgency.|
|Labels||A list of additional custom labels used for categorizing or querying records.|
|Request participants||A list of extra customers who take part in the request, for example, people from other teams or vendors. Read more about participants.|
|Approvers||A list of people responsible for approving the request, usually business, financial or technical contacts.|
|Organizations||A list of customer groups interested in the request's resolution. Learn more about organizations in Jira Service Desk.|
|Impact||The effect of the incident, usually in regards to service level agreements.|
|Urgency||The time available before the business feels the incident's impact.|
|Pending reason||A short description or code that indicates why the incident is not progressing.|
|Product categorization||A category of IT asset or system that the request effects.|
|Operational categorization||A category of action or function required to fulfill the request.|
|Source||The asset or system where the incident originated.|