Making Better Use of Service Request User Input in SCSM – Part 3

At a recent meeting of the Adelaide System Center User Community and also at Cireson Innovate 2015 I did a presented on Self-Service Automation Deep Dive (https://vimeo.com/143957653) and showed several automation techniques that I have used over the years. In this series of blog posts I will explain these techniques, why they are useful and how to go about automating them in your environment. (And maybe even share a Runbook or two.)

In Part 1 we looked at taking the Affected User’s name and placing it in the title of the service request to make it easier to find when looking at a queue of work.
In Part 2 we looked at taking some basic user input text fields and placing them in the Description field of the service request.
In Part 3 we will look at taking a multi select query field and enter each of the results in the description field so they are nicely formatted.

What’s Wrong With User Input?

When an end user enters data in to a service request the results are recorded in properties of the associated SR or any activities that are related to that SR. To try and “Help” the analyst these values are then also displayed in the User Input section on the SR form.

With text and drop down lists the data is shown in a format that is easy to read.

image_thumb3_thumb

Query results however are not as easy.

image_thumb1_thumb

Not only is the select value shown but also the GUID of the item. If the query is set to allow multiple selections, like the one above, there can be multiple values all mixed together.

This is far from simple and some analysts, especially second and third level support, may never actually read this data or understand what it all means.

How Could User Input  Be Used Better?

There are a couple of ways I will cover that I think are the most useful ways to use this User Input data on a day-to-day basis. This data would be much more useful if it was somehow added in a nicely formatted way in the SR description or even key pieces of data in the Title.

In part one we looked at the title only and in Part 2 we will cover the Description field.

Multiple Values in the Description

In this example SR a user can select multiple values from a query of Business Service CI’s that are distribution lists.
Instead of having to use the User Input field to determine what DL to add the user to it would be much easier for the analyst to have this information nicely formatted in the description field for easy retrieval and action.

Like so:

image_thumb6_thumb

Once the user has selected multiple Configuration Items (CI’s) they are then associated with, or related to, the Work Item we are dealing with. (In this case, and in most, the work item is a Service Request)

A Runbook that we might use to update the SR description text with a list of all the items selected by the user (in this case distribution lists) might look a little like this:

Update Description Runbook

Looks fairly simple enough, lets quickly run through it:

  1. Get the Service Request item back from SCSM
  2. Get any Service Request and User relationships
  3. Filter the user CI’s that have been returned to only pass the Affected User
  4. Get the Affected User’s AD User CI from SCSM and update the title of the SR
  5. Get any AD Groups that have a relationship to the SR
  6. Get the Related AD Group and update the Description of the SR with the Distribution list

Seems simple enough. Each AD User group that represents a Distribution List will be found and the value written to the SR Description like so:

Update Description Runbook2

The issue is, that with each AD Group that is found that “Branch” (for lack of a better word) of the Runbook will run once. So if the user selects 3 AD Groups, the branch (labelled #6 in the previous image) will run 3 times.

Instead of appending the AD Group Display name to the description each time, it will over write the description with a new value each time, so the end result will be the last of the 3 groups being listed but nothing else.

To get around this and list each one, we need to do the following:

  1. Read the SR Description as it is right now
  2. Read the Display Name of the AD Group
  3. Write the Original SR Description back to the SR and append the AD Group we just found.

So how do we do this?

To do this we remove the Get AD Group and Update SR activities from our existing Runbook, and replace them with a single Invoke Runbook activity. Like so:

Update Description Runbook3

We then have to create a new Runbook that this will call each time.

Update Description Runbook4

As we described above this Runbook will:

  1. Read the SR Description as it is right now
  2. Read the Display Name of the AD Group
  3. Write the Original SR Description back to the SR and append the AD Group we just found.

The Update SR Description activity just has the description from the Get AD Group activity, plus, the Display Name from the Get SR Object activity. Like so:

Update Description Runbook5

So long as the SR Description field has all the precursor text we want in the template then that will contain the heading for us.

Such as: “Please add this user to the following AD Groups:”

The final output should look something like:

Please add this user to the following AD Groups:
– Social Club
– All Users
– Accounting
– Asia Pacific

Like always, I hope this was helpful.

Advertisements

One comment

  1. Pingback: Making Better Use of Service Request User Input in SCSM – Part 2 | System Center Noise

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s