RT-Extension-ChangeManagement - Change Management configuration for RT


Works with RT 5.


perl Makefile.PL
make install

May need root permissions

Edit your /opt/rt5/etc/

Add this line:

make initdb

Only run this the first time you install this module. If you run this twice, you may end up with duplicate data in your database.

Clear your mason cache
    rm -rf /opt/rt5/var/mason_data/obj
Restart your webserver


To upgrade from an earlier version, see the instructions in the UPGRADING document.


This extension provides the configuration to implement a change management process in Request Tracker.

Organizations working to standardize internal processes for ISO or SOC compliance must have a standardized way to deploy and track changes to software, hardware, infrastructure, etc. This extension implements a change management system within RT, providing a framework for handling a variety of change types. It uses all core RT features, so everything can be modified as needed to align with your organization's practices and procedures. As-is, it provides a simple, fully functional implementation of an ITIL-like change management process.

To provide additional validation and required fields for different stages of the process, you can install RT::Extension::MandatoryOnTransition. An example configuration is provided in the sample configuration file in etc/

We've provided a walkthrough video to demonstrate some of the functionality available in the change management extension.

Change Management Queue

After installing, you'll see a new queue called Change Management for tracking all of the incoming change requests. You can change the name to anything you like after installing. In a typical configuration, you will also want to assign an RT email address, like or (Change Review Team) to create tickets in this queue.


By default, Everyone can see the queue, create tickets, and view tickets. All users can also set custom fields on create, but only then. You can grant more rights if your change requestors need to update custom fields after the ticket is created.

The Change Management group has more rights to work on change tickets including taking ownership and approving or rejecting requests.

Some custom rights are available if you go to Admin > Queues, click on Change Management, then click Group Rights. The "Status changes" tab has specific rights to allow users to "Approve Requests" and "Implement Changes". By default, the Change Reviewer role can "Approve Requests" and the Change Implementor role can "Implement Changes". If this is too restrictive for your workflow, you can grant these to more users, possibly via a group.

Custom Roles

The roles below are allow you to assign different users to parts of the change management process. In addition to clearly identifying who is responsible for parts of the process, these roles can be used to manage rights and notifications like email.

Change Reviewer

Person who reviews incoming change requests, and is responsible for approving or denying a change request.

Change Implementor

Person who is responsible for implementing a change request.


Groups are included to make it easy to add users quickly and give them sufficient rights to interact with the Change Management queue.

The Change Management group gives a set of rights appropriate for staff who will work with chagne management tickets. It allows them to take tickets, comment, change custom fields, etc. You can refine all of these after you install the extension.

Change Management Lifecycle

The Change Management lifecycle provides a set of common statuses. You can update this as needed to add or remove statuses and transitions.


Status given to a new change request. Indicates than a change has been requested and is awaiting approval.


For changes that are approved but not yet implemented.

In Progress

An approved change that is in the process of being deployed.

Partially Deployed

The change has been partially deployed; it is either taking an unusually long time to complete, or part of the deployment succeeded while another part failed. Reasons as to why should be detailed in a comment.


The change has been deployed successfully.


The change failed to deploy. Reasons should be detailed in a comment.


This change was cancelled. Reasoning should be provided in a comment.


The change was rejected by the review team. Reasoning should be provided in a comment on the ticket.

Custom Fields

Some common custom fields are provided to track additional information about changes. The provided custom fields can be modified as needed, to add or remove available values in dropdowns, for example.

You can also add more custom fields as needed. A %CustomFieldGroupings configuration is provided to group custom fields in a Change Management portlet. You can add new custom fields to this configuration to include them in this section.

Change Category

Specifies the kind of change that is to be performed.

Change Type

One of the three types of changes. The initial values are those outlined in ITIL:


A low risk, pre-authorized change that follows a repeatable process. This is the default for new tickets in the Change Management queue.


A change that must be performed ASAP, potentially bypassing approval steps.


Any change that doesn't fall into the other types.

Rollback Plan

A description of the steps necessary to perform a rollback of the proposed changes in the event that the deployment process is unsuccessful.

Change Started

Date that the change was started. This is not the same as the normal Started date on the ticket. Started is set when the ticket is moved to an open status (such as approved); Change Started is when someone actually started implementing the change.

A scrip is provided to automatically set this when status changes to in progress or partially deployed.

Change Complete

Date that the change was successfully deployed. A scrip is provided to automatically set this when status changes to deployed.

Change Management Dashboard

A Change Management dashboard is installed with two saved searches included, one for upcoming changes and one for recently completed changes. These are useful for tracking change tickets and are also good examples of the types of saved searches and dashboards you can create for different participants in the change process.


Since this extension uses core RT features, it's easy for an RT administrator to customize various parts. Below are some ideas.

Additional Custom Fields

Some ideas of fields that could be added to the change management process might include:

Change Origin

Customer, Vendor, Internal. Dropdown.


Datacenter, customer site, etc. Text.

Implementation Steps

Steps needed to implement proposed change. Text.

Validation Steps

Process for validating a change was deployed successfully. Text.

Impact Assessment

A description of what potential side effects of a proposed change might be, what could happen if the change goes awry, etc. Text.

Making Custom Fields Required

Using RT::Extension::MandatoryOnTransition, any of the above fields can be made required upon a status change. For example, you may wish to make Implementation Steps, Validation Steps, and Impact Assessment required fields before a change request can be approved. See etc/ for a ready-to-use example with the out of the box configuration.

Default Values for Custom Fields

As an RT admin, you can go to Admin > Queues > Change Management, then click on Default Values in the submenu. From that page, you can set or change the default values for assigned custom fields.


Best Practical Solutions, LLC <>

All bugs should be reported via email to or via the web at


This software is Copyright (c) 2022 by Best Practical Solutions, LLC.

This is free software, licensed under:

  The GNU General Public License, Version 2, June 1991