Documentation forSolarWinds Service Desk

Change Management

Change Management (CM) is a collective term for all approaches we take to prepare, support, and help individuals, teams, and organizations when making organizational change. Implementation of these changes across your organization can be a complex and cumbersome task, especially when there is direct impact on your business and employees. The SolarWinds Service Desk’s Change Management module helps you plan, execute and communicate change plans seamlessly while following ITIL best practices. It also provides you with visibility to past changes, their root causes, information about which plans worked, which plans didn’t (and why) - so that you and your team continuously improve performance.

Prior to any change, it is best practice to define your: Change, Rollback and Test Plans. In the definitions below, we refer to an example of Upgrading the Router Firmware.

Change Plan

How to respond in the event of a problem. For example, when you need to upgrade the Router Firmware to the latest version. In an ever changing environment, we face many unexpected interruptions, however, at times, the solution can be straight forward. If the solution has worked in the past, no need to re-invent the wheel, document the solution in detail to allow others to repeat the process in the future. See the example Change Plan below:

Upgrade Router Firmware to version (XX.XX.XX).

  1. Copy firmware image to deployment server
  2. Validate the MD5 hash of the image
  3. Confirm communication between deployment server and router (HTTP, SCP, etc.)
  4. Backup existing image from router to deployment server as legacy image
  5. Capture running configuration on router
  6. Copy new image from deployment server to router
  7. Update configuration to include the new firmware image
  8. Save configuration
  9. Reload router

Rollback Plan

Always have a plan B, For example, after preforming the upgrade to the router firmware, if the new image is active on router however issues persist:

  1. Copy legacy image from deployment server to router
  2. Restore configuration from backup
  3. Reload router

Test Plan

How to test for success.

  1. Validate firmware is deployed to router

Some of the most common motivators for change are:

  • Security
  • Maintenance
  • Performance
  • Software upgrades
  • Hardware upgrades and much more

Important factors to consider:

  • Company resources
  • Budget
  • The effect on the organization during the change process
    • Simultaneous change collision - can multiple changes occur at the same time?
  • Moving forward to ensure you deliver organizational success and outcomes

Once an organization determines it is time to make a change many more factors come into play. We have identified four main personas, each playing a vital role in successful completion of the organizational CM process.


As organizations vary in size and maturity, so will the breakdown of responsibilities when change is necessary. While more mature organizations can have the responsibilities of each persona filled by a different individual, smaller organizations can have the tasks required by multiple personas carried out by the same person.

The classification of roles and responsibilities is imperative to:

  1. Ensure clear expectations of each persona and its responsibility in the Change Lifecycle.
  2. Provide each role the appropriate permissions in the system to carry out all approvals and additional tasks required to achieve successful change.

Change Owner

There can be multiple change owners in an organizations, each acting as a subject matter expert of their own domain. The change owner has 4 main responsibilities:

  1. Defines the specific change and the workflow needed to best carry out successful outcomes
  2. Responsible for approving steps and processes along the entire lifecycle of the change process
  3. Constantly oversees that all changes are being processes correctly, which can include bringing in analysts and specialists if needed
  4. Works in conjunction with CABs (Change Advisory Board)

CAB Manager

The responsibilities of this role can be performed by the Change Owner. The main responsibilities include:

  1. Oversee the CAB (Change Advisory Board)
  2. A holistic view of all the changes within the organization to minimize any inherent risks
  3. Always up-to-date on all progress and milestones of the change processes they are involved in
  4. Responsible to approve change templates throughout the CM process lifecycle

Change Initiator

Responsibly for standard changes. This role can be performed by the same person as the Change Implementer (4th persona described below) depending on the criteria of the change and the size of the company. The main responsibilities include:

  1. Submits the Change Request
  2. Reviews and tracks progress of the Change Request

Change Implementer

Responsible for implementing approved changes and at times, for closing the CR. The main responsibilities include:

  1. Completing all assigned tasks related to the specific change
  2. Always up-to-date on all progress and milestones of the change process
  3. May determine that an update in the (Change Request) CR or fields is required and therefore puts in the request for the change within the process to ensure that the CM lifecylcle is achieved smoothly and successfully.

Change is a process that at times impacts many people throughout the organization, therefore it is crucial that we define the change and take all the necessary precautions to ensure positive business continuity while minimizing any disruption of workflow.

Change Management Lifecycle

The CM lifecycle consists of three main phases. Within each phase there are key roles responsible to ensure tasks are carried out in the most efficient manner. As stated above, depending on the size and maturity of an organization, different roles may be carried out by the same individual.

Phase 1 - Change Catalog Creation

In this phase the Change Owner and/or CAB Manager creates and maintains templates, referred to as Change Catalog Items (CCIs). Changes are often unique, however changes from the same family and type may have a great deal in common, therefore, a CCI, that include all the common processes, will expedite the change creation and allow for better planned change processes.

Why do we depend on CCIs?

The CCI provides a predefined template when implementing Change. The use of a template enforces the adherence to ITIL best practices, drives consistency and streamlines Approvals and Execution workflows.

Click here for additional information regarding CCIs

During this phase, the CCI undergoes its own process including three states:

  • Draft
  • Internal
  • Approved

Once the CCI is approved, it is published and ready to be used for future requests.

Phase 2 - Change Request

The Implementer and/or Requester is responsible to Request a change and track the status of that specific Change Request. It is best practice to utilize an existing CCI, however when there isn't a relevant CCI in place, or we are looking to make a one-time change, an Ad-Hoc change can be requested.

If you allow the request of specific CCIs directly from the portal, click here for details.

The Change Request initial and default State is Open.

Phase 3 - Change Implementation

The person assigned to this Change, Owner, CAB Manager and/or Implementer, will review that all fields and processes are accurate. Once confirmed, will press the Start Process button to trigger the process and the approvals.


The first step in the Change Management process in SolarWinds Service Desk is for the administrator to assign relevant users with the proper permissions.

Navigate to Setup > Users & Groups > Roles. All roles that can part take in the Change Management process need the Create and/or Manage permissions.

The following sections explain the CM process and lifecycle in detail. This information is helpful when determining which permissions are relevant to each user.

From the Add Permission button, select the Action from the dropdown menu and Change Catalogfrom the Subject dropdown menu. Click Create Permission to save changes made.

Below we have defined the ability enabled by each permission and provided best practices for which permission is required by each persona. Please make sure only relevant users can make changes in the CM lifecycle.

Change Catalog:

Table 1: Defining the permission

Action Definition
Manage Allows users to create, delete, or update CCIs
Read Allows users to view approved CCIs
Create Allows users to create new CCIs ​​
Update Allows users to update existing CCIs
Delete Allows users to delete CCIs

The table above is based on the given scope: Site - Department - State (Draft/Internal/Approved)

Table 2: Best practice to manage the permissions

Role Permission
Owner Manage
CAB Manager Update
Requester Read
Implementer Update


Table 1: Defining the permission

Action Definition
Manage Allows users to create, delete, or edit a Change Request
Read Allows users to view (only!) ​​

Allows users to: ​

  1. Create new ad-hoc Changes ​
  2. Request Changes using a CCI​​

Allows users to update an existing Change Request. This includes:

  • All editable fields
  • All workflow actions under the Process Tab
  • Modify before/after the Change Process is launched ​​
Delete Allows users to delete a Change Request

The table above is based on the given scope: Site - Department - Requester - Assignee -CC'd on

Table 2: Best practice to manage the permissions

Role Permission
Owner Manage
CAB Manager Update
Requester Create
Implementer Update

Change Catalog

Utilizing your CCI to accomplish seamless changes. On the one hand, many changes are unique however numerous change processes can utilize the same change template (CCI) to achieve successful outcomes. As the templates are editable, the same "Family" (Network, Applications, Infrastructure etc.), and even across families, we can rely on the basic structure of the template and customize it to take into account the specifics relevant to the change being addressed.

All require consideration of factors such as team members affected, budget etc. By creating Change Catalog Items (CCIs) defined here as templates, that include all general processes, you can accelerate the Change Request (CR) process and ultimately the CM lifecycle.

The Change Catalog is a repository of Change Catalog Items (CCI), which are change plan templates that you can predefine for each change type. The use of these templates by change requesters and implementers will help enforce the use of consistent ITIL best practices across your organization, reduce manual processing times and change failures caused by poorly planned changes.

The Change Catalog is now available on your mobile device.


Implementing Change Processes provides numerous benefits across your organization, such as:

  • Driving consistency in routine Change Plans
    • For example: Changing a network router is standard procedure. Whether you want to upgrade or replace a faulty router, over 80% of the change processes are common across all types of routers.
  • Accelerate and streamline Approval and Execution workflows and much more.
    • As in the example above, by providing a template to request a network router change, the organizational process has already been approved and all that is left is to follow the preset guidelines.

Best Practices

To maximize the benefits of smooth and efficient Changes throughout your organization and throughout the Lifecycle of the Change being implemented we have provided the following best practices.

  • Create a unique CCI for every type of change. ITIL defines the 3 main change types:
    •  Standard
    • Normal
    • Emergency

    However many organizations use their unique variations of names to manage their change templates and processes more easily. Therefore we provide the option to define custom change types. This allows to better organize and sort your Change Catalog Items by additional types, for example, ‘Mandatory’ or ‘Maintenance’.

    To create custom change types, select Setup, navigate to Global Settings and click Service Desk Settings.

    • To help you understand how to work with CCI's, we have provided three examples out-of-the-box:

      1. Replace hard drive in server
      2. Operating system update using SolarWinds Patch Manager
      3. Add email server and Spam Experts
  • Include type and "family" in the naming convention (Network, Application, Infrastructure etc.)
  • Assign relevant permissions to allow each role to best carry out their responsibilities in the Change Process. Remember to view the table above to determine which role needs which permission.
  • Attach Incidents to CCI created, as you work, the AI capabilities in your Service Desk will offer relevant Incidents that relate to the CI created.
  • Always keep your Change Calendar up-to-date. For more on your change calendar, click here.

While using Change templates shortens processing times, drive consistency, and reduces human error - it can cause identifying specific changes directly from the index to be more challenging. For example, we can have multiple Change records for backing up a server, all originating from the same template, with the same title.

To help identify these records quickly, you can add a custom title which includes variables from the Change process, such as:

  • Back up {{server_name}} on {{date}}
  • Back up {{server_name}} to {{backup_location}}

Change Catalog Index Page

To view the Change Catalog index page navigate to Service Desk > Change Catalog.

Below you will see the index page breakdown:

Title Description
  • Draft - CCI owner is still working on it
  • Internal - CCI is ready for review process or is being reviewed
  • Approved - CCI is published and ready to be used /Requested
  • Standard
  • Normal
  • Emergency
Name The name does not affect the process and is for your benefit. It is recommended to include the type and family (Network, Application, Infrastructure etc.) in the naming convention.
Description Explain the relevant topics in the change you plan to achieve

Based on the state of the CCI, the following actions will be available:

  • Draft - Delete CCI
  • Internal - Delete CCI
  • Approved - Initiate request of this item or delete

To increase control of the process, you must manually update the State. This ensures the request process does not begin prior to all phases of the plan being put in place.

Create a New Change Catalog Item (CCI)

You can select the icon to reveal the New CCI details page and customize additional CCIs that will help automate workflows within your organization.

Although the Title field is the only mandatory field, it is best practice to enter all common details to provide transparency and clarity for future users of this CCI. As described in the introduction, here is where you define the three critical plans in the process, the Change Plan, Rollback Plan and Test Plan.

The icon provides the ability for others on the team to edit these fields. By disabling this function, others can only view the details without making any changes in later phases of the CM lifecycle.

Therefore you can enable editing in the Change and Roll Back Plans fields however disable it in the Test Plan field which will keep the Test Plan as a constant.

In addition, there are rich text fields. Notice the at the corner of each field. Clicking the gray icon reveals a menu of options.

Notice the tabs on the bottom of this screen, Process and Related.

The Process tab incorporates all the approvers and additional process options.

For example:

  • Task - Add a task to the lifecycle of this change, including the name, description and person assigned to complete task.
  • Group - Add a group to act as a container for multiple steps to occur in a concurrent fashion.
  • Approval - Add an approval steps to capture the needed authorization for this Change.
  • Condition Set - Apply a condition to any record field (including custom fields) in a workflow. By applying a condition you enhance customization of your workflows and increase automation of processes to ensure overall efficiency.

    When you have multiple conditions you are able to streamline processes by selecting the specific condition type needed for this process. For example: By selecting to customize the Operator between conditions you can select, 1 and (2 or 3) or any version necessary.

  • Update Record - Use to automate the Change States as part of your workflow lifecycle.
  • Stop Process - Use as part of the workflow if the Process must be stopped in the middle.

  • Send Notifications - (Available in Professional and Enterprise Plans) this is your automation tool to provide status updates of all processes to relevant stakeholders.

    For example: Once a new laptop is requested, you can set up an automatic notification to be sent when:

    • The new laptop request has been denied - the notification can state denial with reasons why or steps how to follow up for more information.

    • The notification can also inform that the laptop request has been approved and the ship date is XX.XX.XXXX.

    For more information on how to set up email templates for notifications click here.

Click Add Update Record to save your changes.

New Change Request

Once a CCI is in an Approved state, you can:

  • Select the icon from the Change index page
  • Select the CCI name to add a New Change Request or
  • Hover in the Actions section of the relevant CCI row and click Request.

Remember, when creating the CCI you determined which fields are editable moving forward. Therefore, any field that you did not enable editing, will be constant.

The requester completes a variety of details such as:

  • Attach relevant ITSM object such as CI, Incident, Problem etc.
  • Assigned to - Can be individual or group
  • Type - None, Standard, Normal or Emergency
  • Priority - None, Low, Medium, High or Critical
  • From the Process tab you can outline all tasks, approvers, etc. and make changes as necessary.

It is important to enter the Planned Start and End dates. If there is any conflict with an existing scheduled Change, you will be notified immediately.

As you can see from the example above, there is an additional change scheduled for the same time, however the technology does not overlap therefore processing both changing simultaneously will not have an negative impact. You can proceed.

Once you enter all the necessary information click Request at the bottom of the screen to submit your request.

Changes Index

The Changes index page displays all the requested Changes. The icon allows you to filter the view, and below we have provided a breakdown of the default columns reflected:

Remember - by selecting the icon, you can edit the columns in your view, Add, delete or return to default table view.

Title Description
Number Reflects the number of changes that have been requested
State (color coded)
  • In Progress
  • On Hold
  • Waiting for Approval
  • Approved
  • Declined
  • Closed Completed
  • Closed Incomplete
The birds eye reveals a pane on the right and displays the Change details, Change, Rollback Test Plans etc.
Title Name of the requested Change
  • None
  • Standard
  • Normal
  • Emergency
  • None
  • Low
  • Medium
  • High
  • Critical
Assigned To The Change Implementor
Created When the Change request was made
Requester Person complete the request information
Started At When Start Process was initiated, not the Request itself
Last Update When was the last update on this change made
Actions Ability to delete request

By selecting the Change title, the details of the CR are revealed including all plans outlined to carry out a successful change process. The Process tab reflects all approvals/denials and general workflow required to move forward or abort the change.

Once the Change assignee completes review of the CR, he should click Start Process.

To make changes once the process has begun, you can stop the Process by clicking Stop Process, modify the workflow directly in the Process tab and when ready, re-initiate the Process by clicking Start Process once again. Not all changes require a relaunch of the process. Changes such as field values (system and/or custom fields) can be made while process continues.

Ad Hoc Change

Whenever a single use Change is necessary, an Ad Hoc Change is the best way to proceed. This Change does not require nor create a CCI.

For example: Across your organization you are replacing the phone system with VoIP (voice over IP) technology. Once this process is complete, it will not need to be repeated, therefore you can request an Ad Hoc change that will not be saved as a CCI for future use, rather it will just appear as a Change created without a template.

From the Changes index page, select the icon. Select Create New Ad Hoc Change from the dropdown menu. Notice the information requested is similar to that of a CCI with the execution of the Custom Fields that are included in this form.