How to conduct Change Enablement in Team Dynamix (TDX)

Overview

This article is designed to help Purdue IT to understand how to manage the Change processes in TDX. 

To better understand the processes. terminology and work flow for Change Enablement, see "What is Change Enablement (Change Enablement Quick Reference Guide)

The videos below explain how to conduct Change Enablement in the TDX tool, including how to access the Change Enablement desktop, how to create and complete and RFC, and how to review and vote on an RFC. 

How-to videos

To enlarge the videos below for better viewing, click on the "full screen" arrow buttons near the bottom left corner of each video. To view these videos outside of the knowledge base article, click here to watch in Kaltura Mediaspace. 

 

Using Change Enablement Desktops in TDX

This video describes how to use the Change Enablement desktop in Team Dynamix and is intended for viewing by Purdue IT professionals.

Creating and completing an RFC in TDX

This video provides instruction for creating and completing an RFC in Team Dynamix and is intended for use by Purdue IT professionals.

Voting and Reviewing RFCs

This video provides instructions for reviewing and voting on RFCs in Team Dynamix and is intended for Purdue IT professionals.

 

FAQs for RFCs

Q: Why does the RFC workflow keep crashing or looping back to the beginning?

A: If you do not select an Approval Authority in the change ticket, the workflow may loop and/or crash. If you edit the RFC, enter an Approval Authority, save, and restart the workflow, then you should not get this error anymore. Please note that this Authorization section will not be available unless you select a Risk Level.

You may also see a feed entry/notification like the example in quotes below if the RFC was missing an Approval Authority.

"System

Changed Status from In Process to New.

This RFC is being sent back to the beginning of the workflow so that an Approval Authority may be selected.  RFCs cannot be approved without the selection of an approval authority.

To select an Approval Authority, EDIT the RFC and scroll to the Approval Authority field.  If you are unaware of the appropriate approval authority to select, please discuss with your manager or director.  Typically, you will select your own group to approve a change, not a group you are not a part of.

The Service Management Office"

 

Q: Who should I select for Approval Authority?

A: Each Approval Authority is a different list of people who can approve an RFC. If the person creating/editing the RFC does not select the correct Approval Authority, then incorrect people may be notified. The dropdown of available Approval Authorities (CABs, Manager Approvals, etc.) changes based on the risk level of the RFC.

If you do not know the exact authority to select, please ask your manager for further information. If they do not know the exact group but do know a person who should be approving the change workflow, you may click on the "History" or "View Progress" options under the current workflow step. "History" will give you a table of all the workflow steps, including each approval authority and its members (members will be listed under the Details column for the relevant step). You can use the Find function (CTRL+F on Windows, Command+F on Mac, or using the browser actions menu) to search the steps that the person is part of. "View Progress" will show you the entire layout of the RFC workflow and allow you to click on each step for more information.

 

Q: How do I request an update to an Approval Authority?

A: If people need to be removed from or added to a list/Approval Authority, that team's director can submit a ticket to our team (currently IT_SE_SERVICE_MGMT) for that request. If the director is not the submitter/requestor, then they will need to be cc'd or otherwise added to the ticket for approval before we update the list.

 

Q: Why did IT Service Management reject the workflow?

A: The most common reason we reject a change ticket is if you do not enter a peer reviewer for an RFC. When a change ticket is routed to our team for peer review, we add an explanatory note and reject the workflow to restart its process. If you edit the RFC, enter a peer reviewer (using the magnifying glass to search if necessary), and save, then you should not have this issue anymore. You may need to restart/reassign the workflow depending on when you make this edit.

 

Q: Can we create an RFC template for our monthly releases?

A: Yes, there is a way to create a change ticket template and scheduled ticket. As you may know, a ticket template is used to prefill data when a ticket is created and may be selected from the Template dropdown. Much like reports, you may not be able to see a particular template if you are not the owner or your group has not been added for visibility. Please note that as a prerequisite to creating a scheduled ticket, you must have visibility or ownership of at least one ticket template already. Additionally, all creation/editing of ticket templates and scheduled tickets must be done from within the respective ticketing application.

To create a ticket template from scratch, use the "New Ticket Template" option under the gear icon in the top right of the ticketing app.

To create a template from an existing RFC you'd like to work from, go to the Actions menu and select "Create Change Template." Although the new template will pull data from the existing ticket, you can edit any/all details as you would when starting from scratch.

Once you have your desired template, you can use it to create a scheduled ticket. Under the same gear icon in the top right, there is a "New Scheduled Ticket" option.

We encourage the use of templates and scheduled tickets for anything that helps you do your job and the process more efficiently. For example, recurring types of work can be made into scheduled tickets that appear on a daily, weekly, monthly, or yearly basis as needed. If your group uses multiple templates, we recommended that a user be designated as a "Template Master" to make sure that they are all standard. While we can't think of a scenario where a high risk or emergency change could be templated since those are so few and far between, repetitive latent, standard, and normal changes may benefit from this process. More information may be found in the "How to create a ticket template and scheduled ticket" KB article.

Still need help?  Click the 'Purdue IT Request' button to start a ticket.

Print Article

Related Articles (1)

The objective of Change Enablement is to enable calculated and deliberate changes that have clear and transparent risk, impact, benefit and communication .