Incidents

On this page

Introduction

SolarWinds Service Desk (SWSD) helps you maintain order within your organization. Tickets are opened daily and fit under one of two classifications: incidents or service requests.

• An incident is any unexpected interference to a service, thereby disrupting the normal operations and affecting an end user’s productivity. Incidents can occur due to several factors, including an asset malfunction or network failure. Incident examples include issues related to printers, Wi-Fi connectivity, email service, laptop crashes, user authentication, and file sharing.

• A service request is a request from a user for information, advice, a standard change, or access to a service. Service request examples include requests for new equipment, software installation, access to files or the network, and information such as cloud or email storage limits.

  There are occasions when a service request is created but should be an incident ticket. You can convert service requests to incidents.

Lifecycle from creation to resolution or close

There are several ways to create (open) a new incident or service request:

• Via the user portal
• Via email
• Through an import from SolarWinds Platform
• Direct contact with an IT professional. For example, someone from IT who stopped in the hallway and provided assistance could then return to his workstation, open an Incident ticket, document the solution, and close the ticket immediately.

Through documented issues and resolutions your organization can maintain organized Incident management.

After an incident is created, the incident ticket goes through several states in SWSD before it is considered closed or resolved. It is important to understand the definition of each state to most effectively address the issues contained in the incidents.

State	Definition
New	Agent Creation (phone call, walk-up, Skype/Zoom, or other method of contact not listed below). Here, your technicians create Incidents on behalf of users who called or contacted an IT professional to report an issue. Email (most common form of Incident creation). Effective way for your end users to submit incidents. It is highly recommended you make sure your incident forms require all vital information that will allow you to begin addressing the issue at hand. This will prevent time consuming back-and-forth correspondence while you request additional data. Be sure that email settings are established. SolarWinds Platform. All Incidents coming through the SolarWinds Platform are entered as an email Incident. Service Portal. The Service Portal enables end users to submit Incidents and Service Requests via custom service forms that collect all relevant details for quick and seamless resolution of tickets.
Assigned	Groups. A collection of users from the same functional team (for example, IT, Finance, or HR). When an Incident is assigned to a group, you ensure that no ticket goes unnoticed or is delayed if an agent is on vacation or working on other matters. After a ticket is assigned to a group, it can be reassigned as needed. Incident Routing. Automatic assignment of Incidents saves time by ensuring all Incidents are visible to the most appropriate team/service agent as quickly as possible. Additional information is available in Understand incident routing in SWSD. Filtering. After Incidents display on the Incidents Index page, you can filter incidents to view information relevant to your needs. Filtering options include Category, Assignee, and State.
In Progress	The In Progress state is relevant only after the Incident has been assigned and an agent is actively working to resolve the issue at hand. Information relevant to the In Progress state includes: Comments. Comments can be public (including your end users) or private (only internal team members will have access to private comments). See Notifications for more information on who is notified when a comment is added. Comments support @mentions. Relationships. Creating relationships allows you to attach relevant assets, problems, solutions, or other information to the current Incident. States. Ticket States include Escalated to Vendor, Awaiting Input, and more.
Awaiting User	After someone has reached out to the user via the Incident, the Awaiting User state can be used to reflect that you are awaiting a response from the requester before you can proceed with the Incident. SolarWinds recommends that you automate a process to ensure that as soon as a public message is received when a ticket is in the Awaiting Progress state, the ticket state automatically returns to In Progress.
Resolved	The Resolved state reflects that the Incident has been addressed to the best of an agent's ability. A public Incident index should be entered to let the end user know the issue has been resolved, and a resolution code with Incident index should be provided. A Resolution Code is a pre-established code that identifies how a ticket was resolved. Resolution codes can be used for reporting purposes. When resolving a ticket with related incidents attached, you will be offered the opportunity to add the resolution code to all incidents that are related. To attach a resolution code to all related incidents, navigate to the Related tab. A Resolution Comment allows agents to summarize the work done to resolve an issue. Such information can be used to solve future similar incidents.
Closed	The Closed state can used to identify an incident that is closed but not resolved. This state can be used in a number of ways. For example, if an agent requested information and the requester did not respond over an extended period of time, the ticket can be closed. Closed tickets can be reopened. If requester continues to experience a challenge, a new ticket needs to be opened.
Forwarded	For ESM customers only. The Forwarded state is autogenerated when a ticket has been forwarded to another service provider. This state is hardcoded (but translated), therefore, it is not editable.

Factors to consider

• What is the most efficient flow through your service desk?
• How can you ensure tickets don't get overlooked?
• Do the out-of-the-box states address all the needs of your organization or does it benefit you to also create custom states?

Best practices

• Automate the Incident/service request creation process. For example, create tickets automatically when received via email or through the service portal. Be aware that a new incident can evolve from several origins (see the table below).
• Encourage an organizational environment that uses submission of Service Requests whenever possible rather than break-fix Incidents tickets.
• Set up queues to automatically route (assign) your Incidents to the correct group or agent (while a ticket is in the queue, it is awaiting assignment).
• Create relationships among relevant areas of your SWSD. Connect Incidents with similar issues, previous helpful solutions, useful Knowledge Base articles, and more, to enhance the end user experience. You can also attach laptop incidents to their respective assets. The historical record of associated previous incidents can provide justification for replacing a piece of equipment.
• Automate the updating of ticket states when possible. For example, while a ticket is Awaiting Input (waiting for the requester to provide more information), you might want to ensure that as soon as a public message is received, the ticket state automatically returns to In Progress.
• Auto-close inactive tickets. If a ticket has awaited a response from the requester for a significant amount of time (5-7 business days), you could automatically set the state to Closed.
  
  The worker that automatically sets the state to Closed runs once per night. If the condition matches on the resolved inactive incident duration when the worker runs, the status is changed on the same day, if not, it changes the next time the worker runs, which would be the next day.

Incidents index page

See List view for information on how to filter, edit, and customize contents of the index page to best meet your needs. You can also learn how to search, add new records, perform actions such as import and export, and find a description of the index page using the buttons in the upper right corner.

See Incidents index for more information about:

• Columns in the Incidents index table
• Best practices
• Icons available on the page
• How to look at an individual incident
• How to identify redundant tickets
• What actions are available directly from an incident
• How to convert an incident to a service request

Incidents details page

From the Incidents index page you can click any Incident title to open the details page. The details page contains information such as:

• Incident number
• Incident state
• Assignee
• Priority
• Category and subcategory
• Description
• Comments, details, process, related items, related assets, tasks, and audit
• Suggestions for similar incidents and related configuration items
• SLA

Dynamic Forms for incidents

You can use Dynamic forms to dynamically change what fields or forms are presented based on user selections. For example, if the priority of an incident or service request changes, dynamic forms can present certain fields in a form when the priority changes. Or if you want to show only certain options in a form after a user enters data, dynamic forms allow you more control over what to show and when to show it. For more information, see Dynamic form rules

Create a new incident from the Incidents index table

1. Click the Add icon in the upper right.

2. Enter all the details requested. 

3. As soon as you begin entering information in the Incident title, notice the AI list that displays to the right:

   • Similar Incidents. A direct link to all incidents that have similar key terms.
   • Smart Solutions. A direct link to all solutions that have worked in the past.
     
     These links to incidents and solutions help you quickly and efficiently address the issue without needing to wait for agent intervention.
4. Provide required (*) and optional information.
   1. Requester (email or Name) *
   2. Title *
   3. Description
   4. Category and Subcategory
   5. Assigned to
   6. Priority
   7. Due at
   8. CC
   9. Site and Department
   10. Related Assets
5. If you are unable to resolve the issue on your own, complete the requested details and scroll to the tabs at the bottom.
   • Related Tabs is a simple way to attach related ITSM objects, such as solutions or other tickets, to the current Incident. Attaching related-ITSM objects allows you to:
     • Consolidate resolution of tickets.
       When you resolve the main ticket you’re working on, you are given the option to resolve all attached incidents.
     • Escalate to a problem or a change.
       You may have noticed a larger trend with the incoming tickets and may want to escalate to a problem or a change. Attach the common tickets and create a problem or change record from the incident record to build the hierarchy of the escalation.
   • The Tasks tab is used to set up a work flow to resolve the issue.

Create a new incident via email

To create a new incident via email, end users send an email to the email address provided by their service desk. Upon receipt of the email, SWSD creates the ticket automatically.

Troubleshoot: Emails not generating new incidents

Create an incident on behalf of another user

See use case: Create an incident on behalf of another user for detailed instructions.

Use a response template in a comment

Agents can add a saved response template to a comment in an incident or service request ticket. See Response templates.

Attach a solution to an incident

During the creation of a new incident or when working an incident ticket, you can add a solution as a related item.

Understand incident routing in SWSD

Incident routing is an imperative action that can be automated by your Service Desk. Automatic assignment of incidents as they are created will save time by ensuring all incidents are visible to the most appropriate team/service agent as quickly as possible so they can begin addressing the issue at hand.

Administrators can set up automation rules to route incidents based on a variety of factors. For example, you can auto-route tickets based on:

• Account Default Assignee
• Sites
• Departments
• Categories
• Subcategories
• Service Catalog Default Assignees
• Automations

Set up incident routing

Select the most appropriate path to ensure fast and efficient handling of each Incident routed through SWSD.

Account Default Assignee

A default assignee can be selected for all new incidents created. This is most beneficial when uncategorized tickets are created in the system from incoming emails.

Default Assignee and Notifications

You can select a default assignee to receive notifications upon creation of each new incident.

Sites or Departments

If you determine the best route for a ticket is for it to go to a specific site or department, you can select the site or department as a default path. For example:

• Site (could be used for all Incidents originating from the New York office to route them to the New York site).
• Department (could be used for all IT-related Incidents, regardless of location, to route them directly to the IT department).

You can select a default Site or Department when creating a new site/department or when editing an existing record.

Category or Subcategory

You can set the category or subcategory as a key word that determines the best route for an Incident.

For example, whenever the category is desktop, the ticket could get assigned to the IT Help Desk.

Service Catalog Default Assignee

A Default Assignee can be selected for each Service Catalog item created. This can be selected when creating or editing each item.

Automation rules

SWSD provides a number of default assignments that can route tickets quickly and efficiently. If you set up multiple automation rules, the ticket will quickly be filtered after it is created in the system. The latest rules will take precedence and if no rule applies, the ticket remains unassigned.

Special permissions to increase visibility, collaboration, and access

Administrators create special permissions to increase visibility, collaboration, and access for users who would not normally see an incident based on their assigned role or team membership. For example, a special permission might allow someone to @mention or CC a member of the computers team on an incident ticket so that person could see or manage an incident assigned to mobile devices team.

See Add permissions for more information.

Use a runbook to resolve an incident

Runbooks document processes in an automated workflow. In SolarWinds Service Desk (SWSD) these runbooks help to structure the naturally unstructured process of incident resolution by documenting best practices established by experts or experienced agents. See Runbooks.

Forward a ticket from one ESM service provider to another

For customer using ESM, your end users or requesters may inadvertently create a ticket for the wrong service provider. SWSD's ticket forwarding functionality is designed to efficiently route tickets to the correct teams or individuals, thereby enhancing the resolution process and customer satisfaction. This feature enables agents from the original provider to transfer tickets to other providers when necessary.

Initiate ticket forwarding

To initiate ticket forwarding when an incident is not relevant to the initially submitted service provider, follow these steps:

1. Click Actions, and select a forwarding action.

   You are prompted to:

   1. Select the appropriate service provider from those enabled in your organization.

   2. Add a comment for the agent of the chosen service provider. The message will be marked as private within the selected service provider.

   3. Click Forward to complete the process.

After a ticket is forwarded

1. The original ticket's status is automatically transitioned to Forwarded, and it is Disabled with no option for editing. It is also updated with a comment and an audit record providing the target Service Provider name, timestamp, and the name of the agent who forwarded the incident.

2. A new ticket is created for the targeted service provider. It features a public comment and an audit record providing the target Service Provider name, timestamp, and the name of the agent who forwarded the original incident ticket.

Simultaneous notifications upon successful forwarding

• The initiating agent receives a confirmation on delivery.

• The requester receives an email explaining that on a new ticket was created for in the targeted service provider's account. The email includes the public message that indicates the requester's ticket was forwarded.

• The targeted provider's agent receives an email regarding the forwarded ticket.

Incident origins

The list below identifies the possible origins for incident tickets.

• Mobile: MobileApp / web mobile format
• Chat: SolarWinds Service Desk internal chat
• Microsoft Teams
• Slackbot
• Web_chat: Virtual Agent API
• External: portal web
• API
• Process_test: workflow test mode
• Web

Related topics

• Automation rules
• Categories
• Chat for agents
• Change incident comments from private to public
• Comments
• CSV file imports, updates, and exports
• Field logic
• Incidents index
• Incidents Management reports
• Mobile application: Incidents
• Reports 
• Response templates
• Runbooks
• Create an incident on behalf of another user