Service Manager Change Request Validation (SCSM and Orchestrator Validation)

Author by Nathan Lasnoski

In the process of change management it is important to ensure quality of change content prior to approval occuring.  A change without start date and end date for instance can be difficult to approve or even act on.  In the same way, this process of validation needs to be efficient vs. requiring large amounts of valuable time.  This blog will show how to use Orchestrator to manage your validation processes after the change has been submitted.   As a start of our configuration you can see that we've configured a change process with five primary stages:

  1. Initial Screening (or Drafting)
  2. Primary Owner Approval
  3. CAB Approval
  4. Change Deployment
  5. Post Implementation Review

0. Process In this case we've completed the "Initial Screening / Drafting" stage and we're moving into the Primary Owner Approval.  We automatically populate the appropriate Primary Owner and the following CAB group based upon the Business Service as described in this blog: 1. Initial Screening Completed We've also included an additional step called "Review Impact on Disaster Recovery", which I explain the implementation of in this blog:   The question is, what if a Business Service was never associated to the Change Request and we therefore could not associate a Primary Owner or set a change control?  We could leave the issue open and wait for manual intervention, or we could use intelligent automation to solve the problem.  For that, we'll turn to Orchestrator.   The process after the initialization in Orchestrator includes many different components, but ultimately it is pretty simple.  We are looking for activities which have been completed which match the quality of being "Completed" and have a default status of "New" set, which we defined in our custom management pack.  You could also use a monitor for this same purpose, but I prefer to use flags as I am not dependent on the "update" process occurring. 2. Get Initial Screening Activities I describe this process in detail here:   In this stage we'll perform the important step of validation.  We look at the content of the Change Request and run through various tests, such as the existence of a start date and end date of the request. 3. Validate Change You'll notice that I am able to perform a "if exists" test using simply "if ($StartDate) { }".  This is easier and faster, plus we can then use the else scenario to set our success to "False", which will then determine the branch we use.   In the success branch we move into our other change processes and hand off to the Primary Owner approval and then to the CAB.  In the failure scenario we essentially set the activities back to the way they were before they were completed and send a rejection email back to the "Created By User", as in this filter.   In the failure branch we need to set the original manual activity back to "In Progress" vs. allowing the process to continue forward. 3.1 Set Activity Status The "Primary Owner Approval" task will then be set back to "Pending" until the proper information has been completed for the change. 3.2 Set Activity Status to Pending We then send the email to the "Created By User" to inform that the change did not pass the required criteria to move forward to the next stage. 4. Filter on Created By User I hope this helps you see how you can use filtering to validate change control processes, insert users into approvals, and control changes through additional protections.   Cheers,   Nathan Lasnoski


Nathan Lasnoski

Chief Technology Officer