Documentation forSolarWinds Service Desk


On this page


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 a number of factors, including an asset malfunction or network failure. Incident examples include issues related to printers, wifi 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.

Incident lifecycle from creation to resolution or close

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

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

Through documented issues and resolutions your organization is able to 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
  • 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.
  • Orion.
    All Incidents coming through the Orion 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.
  • 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 appear 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.
  • 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 requestor 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.


The Resolved state reflects that the Incident has been addressed to the best of an agent's ability. A public Incident index table should be entered to let the end user know the issue has been resolved, and a resolution code with Incident index table 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.

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.

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 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.

Incidents index table

The Incidents index table reflects All Incidents by default. (See List view for information on how to filter, edit, and customize to best meet your needs. More information about views is available in Service Desk Agent.)

See Incidents index table 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

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 appears 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. 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 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 will be 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.

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 un-categorized 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.

Related topics