Change Management Status in SCSM using Orchestrator and Custom Fields

Author by Nathan Lasnoski

Service Manager is a very activity-centric platform.  This means that work processes with multiple steps are the combination of both the container process (such as Change Management or Release Management) and its sub-activities.   This means that the status of a process, such as a Change Request, is the aggregate of its activities.  However, that status does not bubble up to the Change Request view.  When you look at a Change Request, you will notice that it is "In Progress", even though it has an activity with a particular name that is "In Progress", with others "Pending".  We needed a way to represent this status to the Change Request itself vs. just by aggregating the activities.   We came up with a solution.   You can see in the example below that we have Change Requests with an "In Progress", "Failed", etc. status.  That status does not include sub-activity tasks. You can see in the example below that we have interior to the Change Request activities which are "Completed", or "In Progress", though the overall status of the Change Request is "In Progress".  The quest was to provide easy, field-based, Change Request status to power both views, reports, and view data.  The solution was to do the following:  

  • Activity Status: AC_Status
  • Change Request Status:      CR_Status
  • Orchestrator process for      updating fields
  • Views for displaying Change      Requests based on CR_Status

  The completed solution presents specific views on Change Requests in different states, as well as presenting that information for reports, and on a Change-by-Change basis.  The completed solution looks like this in the console:   The Orchestrator runbooks that support this are relatively simple.  They essentially grab activities that are "Completed", but the "AC_Status" is "New".  This works because when the Change Request is instantiated in Service Manager all the activities in the Change Request have a status of "New", as does the Change Request.  The completed solution has one runbook per Activity in the Change Management process.   Here is an example of the entire process: The first step in the process is to retrieve the activities which have been "Completed", but were previously "New". The second step is the update the activity "AC_Status" to "Completed". The third step is to update the Change Request "CR_Status" to reflect the activity progress and send an email to the appropriate individuals on the project.   This process has worked for me in many projects and I hope it aids you at creating Change Management views which are more usable for your end users.    Have a great day!   Nathan Lasnoski


Nathan Lasnoski

Chief Technology Officer