Documentation forSolarWinds Service Desk

Change management

On this page


Change Management is a collective term for all approaches taken to prepare, support, and help individuals, teams, and organizations when making organizational change. Implementation of changes across your organization can be a complex and cumbersome task, especially when your business and employees are directly affected.

In SolarWinds Service Desk (SWSD), the 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, and which plans didn’t (and why)—so that you and your team continuously improve performance.

Here the Change Lifecycle is described in detail. Continue to read as outlined or click on the links below to go directly to the topic of interest.

Common motivators for change

Some of the most common motivators for change are:

  • Security
  • Maintenance
  • Performance
  • Software upgrades
  • Hardware upgrades

Prior to making any changes, consider the following factors:

  • Company resources
  • Budget
  • The effect on the organization during the change process (for example, the possibility of a simultaneous change collision).
  • How you can ensure you deliver organizational success and outcomes.

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

Define change plans

Prior to any change, it is best practice to define your change, rollback, and test plans.


The definitions below refer to an example for upgrading router firmware.

Change plan example

A change plan describes 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, you face many unexpected interruptions, but at times, the solution can be straightforward. If a solution has worked in the past, there's no need to re-invent the wheel. Instead, document the solution in detail to let others repeat the process in the future. See the example change plan below:

Change plan: 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. Back up 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 example

Always have a plan B. For example, after performing an upgrade to router firmware, if the new image is active on the router but previously existing issues persist, you would need a rollback plan.

Rollback plan: Roll back upgrade of router firmware to version (XX.XX.XX)

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

Test plan example

It is important to test for success.

Test plan instructions

Test plan: Validate firmware is deployed to router.


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

The classification of roles and responsibilities is important to:

  • Ensure clear expectations of each persona and its responsibility in the Change Lifecycle.
  • 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 organization, each acting as a subject matter expert of their own domain. The change owner has four main responsibilities:

  1. Defining the specific change and the workflow needed to best carry out successful outcomes.
  2. Approving all steps and processes along the entire lifecycle of the change process.
  3. Constantly overseeing all changes to ensure they are being processed correctly. This can include bringing in analysts and specialists, if needed.
  4. Working in conjunction with CABs (Change Advisory Boards).

CAB manager

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

  1. Overseeing the CAB (Change Advisory Board).
  2. Taking a holistic view of all the changes within the organization to minimize any inherent risks.
  3. Staying up-to-date on all progress and milestones of the change processes the CAB Manager is involved in.
  4. Approving change templates throughout the Change Management process lifecycle.

Change initiator

The Change Initiator is responsible for standard changes. This role can be performed by the same person as the Change implementer, depending on the criteria of the change and the size of the company. The main responsibilities include:

  1. Submitting the Change Request.
  2. Reviewing and tracking the progress of the Change Request.

Change implementer

The Change Implementer is responsible for implementing approved changes and, at times, for closing the Change Request. The main responsibilities include:

  1. Completing all assigned tasks related to the specific change.
  2. Staying up-to-date on all the progress and milestones of the change process.
  3. If needed, determining that an update in the Change Request or its fields is required. If that is the case, the Change Implementer puts in the request for the change within the process to ensure that the Change Management lifecycle is achieved smoothly and successfully.

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

Change management lifecycle

The Change Management Lifecycle consists of three main phases. Within each phase there are key roles responsible for ensuring 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 Phase 1, 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 includes 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 for implementing Change. The use of a template enforces the adherence to ITIL® best practices, drives consistency, and streamlines Approvals and Execution workflows. For additional information regarding CCIs, see Change Catalog.

During Phase 1, the CCI undergoes its own process including three states:

  • Draft
  • Internal
  • Approved

After 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 for requesting a change and tracking the status of that specific Change Request. It is best practice to use an existing CCI, however when there isn't a relevant CCI in place, or you are looking to make a one-time change, an Ad-Hoc change can be requested.

The Change Request initial and default State is Open.

Phase 3 - Change implementation

The change assignee, owner, CAB Manager, and/or implementer, reviews to ensure all fields and processes are accurate. After confirmation, the person presses the Start Process button to trigger the process and the approvals.


The first step in the Change Management process in SWSD 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 Create and/or Manage permissions.

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

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

The tables below identify the action enabled by each permission and best practices for which permission is required by each persona. Make sure only relevant users can make changes in the Change Management Lifecycle.

Table 1 - Defining the permission

Scope: Site - Department - State (Draft/Internal/Approved)

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

Table 2 - Best practice to manage the permissions

Role Permission
Owner Manage
CAB Manager Update
Requester Read
Implementer Update


Table 1 - Defining the permission

Scope: Site - Department - Requester - Assignee - Copied

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

Lets users: ​

  • Create new ad-hoc Changes ​
  • Request Changes using a CCI​​

Lets users 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 Lets users delete a Change Request

Table 2 - Best practice to manage the permissions

Role Permission
Owner Manage
CAB Manager Update
Requester Create
Implementer Update

Change catalog

SolarWinds recommends you familiarize yourself with the Change catalog to better understand its features and how to use it.

Changes index page

For information on the Changes index page, see Changes.

Ad Hoc changes

Whenever a single-use change is necessary, an ad hoc change is the best way to proceed. It neither requires nor creates a CCI.

For example, across your organization you are replacing the phone system with VoIP (Voice over IP) technology. When the change process is complete, it will not need to be repeated. You can request an ad hoc change that will not be saved as a CCI for future use. Instead, it will display as a change created without a template.

  1. From the Changes index page, click Add .

  2. Scroll to the bottom of the dropdown menu and click Create New Ad Hoc Change.

    In the New Ad Hoc dialog, notice the information requested is similar to that of a CCI with the execution of the Custom Fields that are included in this form.

Restrict ad hoc changes

You can restrict roles from creating ad hoc changes. See Roles and Permissions for more information.

Related topics