SCSM 2012

SCORCH 2012 – How To: Get Service Request User Input from SCSM 2012

Hello again,

Today’s topic is a little advanced, and needs a bit of experience with Orchestrator and Service Manager, but I will try to explain as much as I can anyways.

System Center Service Manager 2012 gives you the ability to create ‘Request Offerings’ and publish them to the ‘SM Portal’. A request offering will allow you to collect user input via the portal, and map the data you collected via the portal to fields on your ‘Service Request’ or ‘Incident’ and any of their child ‘Activities’.

To learn more about ‘Service Offerings’ and ‘Request Offerings’ before going any further, please check out these two blog posts by Kurt Van Hoecke and Travis Wright:

This might sound straight forward, however one limitation is that you cannot bind the results of ‘Query Result’ prompts directly to a field. As the ‘Query Result’ prompt will let the user choose either a ‘Work Item’ or a ‘Configuration Item’, and those are complex types. SCSM has no idea how to bind those types to a field.

So this is where we’re going to come in with a bit of System Center Orchestrator magic. To extract the values of the ‘User Input’ from the ‘Service Request’.

First of all let’s take a look at how a ‘Service Request’ saves the ‘User Input’ value. If you try to query a ‘Service Request’ via PowerShell, the ‘User Input’ will be generated as XML text. Containing all the prompts and their results as defined in the ‘Request Offering’. A Typical ‘User Input’ would look something like this:

As you can see from the XML, the ‘User Input’ value consists of a main tag ‘<UserInputs>’ which has many child tags ‘<UserInput>’, one for each prompt defined in your ‘Request Offering’.

The ‘<UserInput>’ tag has three attributes: Question, Answer and Type. The ‘Question’ attribute is the name of the prompt as defined in the ‘Request Offering’, the ‘Answer’ attribute holds the value chosen by the user in the portal. The ‘Type’ attribute tells Service Manager what is the class type that this ‘Answer’ attribute is holding, may it be a number, rich text, enum, or as in our case it would hold the a user or group value from the people picker control.

For complex types, like the ones are generated when the prompt is designed to hold ‘Query Results’, the ‘Answer’ attribute will actually hold more XML data, containing the count, display name, and Id of each item chosen by this prompt (because ‘Query Result’ prompts support multiple selection.

So basically what we will do is build an Orchestrator Runbook, to help us get the Ids of the items chosen by the ‘Query Results’ control. A typical use for that is you can later use those Ids to get certain ‘Configuration Items’ using them, thus performing automation for the service request once it has been created.

First, start by firing up the ‘Runbook Designer’ and create a new folder for your runbook, then create a new runbook.

Drag an ‘Initialize Data’ activity from the ‘Runbook Control’ tab on the right. Configure it to receive two inputs:

  • ‘SRID’ (which is the Id or Name of the ‘Service Request’)
  • ‘UserInputQuestion’ (which is the ‘Question’ or prompt you will try to get the answer to as defined in the ‘Request Offering’)


Now, drag a ‘Get Object’ activity from the SC Service Manager 2012 integration pack tab, and configure it as shown below.




Now, open the ‘Utilities’ tab from the right pane in ‘Runbook Designer’ and drag two ‘Query XML’ activities.

We will call the first one ‘Get Raw Answer’ to get the whole  ‘Answer’ attribute to the ‘Question’ and we will call the second one ‘Get Guid Answer’ to further parse the XML inside the answer and get the ‘Id’ values of the chosen ‘Query Results’

For the ‘Get Raw Answer Activity’, configure it as shown below:


As you can see, I have set the ‘XML Text’ value to get the ‘User Input’ from the ‘Get Service Request’ activity. And also set the ‘XPath Query’ value to the following:

/UserInputs/UserInput[@Question='{UserInputQuestion from Initialize Data}']/@Answer

This ‘XPath Query’ will extract the ‘Answer’ attribute for the specified ‘Question’ from the ‘User Input’ XML.

Now for the ‘Get Guid Answer’ activity, configure it as follows:


I have set the ‘XML Text’ value to the ‘Query Results’ from the previous activity ‘Get Raw Answer’, this will parse the XML inside the ‘Answer’.

And the ‘XPath Query’ value to


Which will return the Id value for each of the ‘Values’ chosen in the ‘Query Results’ so we might get multiple responses from this activity.

So far the runbook should look something like this:


Now let’s define some output for our runbook, I have chosen the output to be as follows:

  • Raw Answer (This will hold the raw answer, whether it is plain text, number, or query results)
  • Guid Answer (This will hold the ‘Id’ value of the chosen result, only in case the ‘Answer’ is of type ‘Query Results’)
  • Answer Type (This will specify whether the ‘Answer’ is ‘Raw’ or ‘Guid’ so you can do some filtering in case you need to exclude raw answers for example)
  • Answer Count (This will specify the number of values chosen in the ‘Query Results’ prompt, to be able to detect multiple selection)

So let’s define our returned data for this ‘Runbook’, right click the tab that has the runbook name above and choose ‘Properties’


Go to the ‘Returned Data’ tab and configure your runbook output as follows:


Now the next part is the trickiest, because you can have two kinds of answers. It’s either a valid Guid or just a Raw answer, you will be able to determine so by checking whether the ‘Get Guid Answer’ activity fails or succeeds, if the activity fails, then it failed to get a valid Guid from the //@Id‘ XPath Query. If it succeeds, then the XPath Query found Id attribute(s) within the provided XML.

Now from the ‘Runbook Control’ tab on the right, drag two ‘Return Data’ activities, and place them as follows:


Notice that I have added link coloring and description so I would be able to refer to the links by name.

For each of the ‘Return Data’ activities, please apply the following configuration.

For the ‘Return Data – Raw’ activity:


I have set the ‘Returned Data’ as follows:

  • Raw Answer: ‘Query Results’ from ‘Get Raw Answer’ activity
  • Guid Answer: Empty (because in this case, there wouldn’t be any Guids in the answer)
  • Answer Type: ‘Raw’
  • Answer Count: ‘Number of matches’ from ‘Get Raw Answer’ activity (However I know in this case it would always be 1. Unless somehow you were able to define multiple questions with the same name.

For the ‘Return Data – Guid’ activity, set the following configuration:


For this activity, I have set the ‘Returned Data’ as follows:

  • Raw Answer: ‘Query Results’ from ‘Get Raw Answer’ activity (As I want to return the raw answer anyways)
  • Guid Answer: ‘Query Results’ from ‘Get Guid Answer’ activity (In this case, this will actually hold the value of each extracted Id within the answer)
  • Answer Type: Guid
  • Answer Count: ‘Number of matches’ from ‘Get Guid Answer’ activity (The total number of matches for the XPath Query, which is the total number of Ids found in the answer)

The next step is telling Orchestrator, to which activity it should direct the flow, I have configures the link named ‘Guid Answer Failed’ which should direct me to the ‘Return Data – Raw’ activity as follows:


To do the same just double click the ‘Guid Answer Failed’ link, go to the ‘Include’ tab, and set it to include results where ‘Get Guid Answer’ returns failed.

On the other link, named ‘Guid Answers > 0’ configure it as follows:



I have set the ‘Include’ tab to include results where ‘Get Guid Answer’ return success, and the ‘Exclude’ tab to exclude results where the ‘Number of matches’ from ‘Get Guid Answer’ equals 0. This is because I want to make sure that you only return a Guid if there are any returned from the activity.

Now just to make sure that the flow is not error prone, I will add some other conditions and link coloring to some of the links, that I don’t want to bore you with.

So the final runbook looks like this:


Now you can check in the runbook, and create another runbook to test it, using the ‘Invoke Runbook’ activity from the ‘Runbook Control’ tab.

Here are the test results of the runbook with different inputs:

Input Output
  • SRID: SR-17072
  • UserInputQuestion: Request For
  • Raw Answer: <Values Count=”1″><Value DisplayName=”test automation6″ Id=”7aa4f3a5-bd1e-c5ea-4373-433db94b5b16″ /></Values>
  • Guid Answer: 7aa4f3a5-bd1e-c5ea-4373-433db94b5b16
  • Answer Type: Guid
  • Answer Count: 1
  • SRID: SR-17072
  • UserInputQuestion: Add To Group(s)


  • SRID: SR-17072
  • UserInputQuestion: Request Justification
  • Raw Answer: Testing
  • Guid Answer:
  • Answer Type: Raw
  • Answer Count: 1


Good luck creating your own,

Hazem Elshabini


SCSM 2012: Notification Subscriptions Vs. Notification Workflows

Hello again,

After having to deal with a lot of notifications in System Center Service Manager 2012, I thought I could illustrate the main differences between the two ways of sending notification emails.

Both Subscriptions and Workflows are translated into ‘Rules’ in the SCSM database, these rules are evaluated each time an object is created, updated or upon a certain period. So keep in mind, when it comes to rules, the less the better.

Comparison area Notification Subscriptions Notification Workflows
Scope Subscriptions can be scoped to a certain ‘Queue’ of Work Items. Workflows automatically apply to all instances of a specific Work Item.
Diversity Subscriptions can be created for any kind of instance in SCSM 2012, including Configuration Items as well as Work Items. Workflows can only be created for instances of these base classes and their extensions:

       ·        Activity

       ·        Change Request

       ·        Incident

       ·        Configuration Baseline

       ·        Release Record

       ·        Service Request


You can easily tell that you cannot even create a workflow for instances of the ‘Problem’ class

Events Unlike workflows, subscriptions add the ability to send periodical notifications as long as an object meets a specific criteria.


For example: You can create a notification subscription to keep notifying the service desk about incidents that are breaching your SLA.

Workflows can be only triggered in the following two events:

       ·        An object is created (optionally with specific criteria)

       ·        An object is Updated (optionally from/to specific criteria)

Functionality Subscriptions do not have any functionality other than notifications. Unlike subscriptions, Workflows give you the ability to apply templates to the objects that trigger them. Giving you a way to change any property of that object.


For example: You can create a workflow to automatically set an incident’s ‘Status’ to ‘Resolved’ when a certain field contains ‘Resolved’ keyword, by applying a template of the incident class with the ‘Status’ pre-set to ‘Resolved’.

Static Recipients Subscriptions have the ability to include static recipients to send the notification to. There static recipients are chosen from SCSM’s Configuration Items. Workflows cannot send notifications to static recipients, all the possible recipients must be directly related to the object that triggered the workflow.
Related Recipients When it comes to recipients, Subscriptions give you a much larger functionality than workflows in that area.


Subscriptions have the ability to choose a User recipient directly related to the object that triggered it, or from any of the User objects that has a relation with other objects with the object triggering the subscription.


For example: You can create a subscription to send a notification to the ‘Assigned To User’ of the ‘Change Request’ which has a ‘Contains Activity’ relationship with the ‘Activity’ triggering the subscription.

Workflows can only send notifications to the User recipients which are directly related to the triggering object.
Notification Templates One drawback of subscriptions, is that you can only choose one ‘Notification Template’ per subscription. Thus preventing you from sending multiple notifications to multiple recipients, each with a different notification template.


The workaround is to repeat the creation of each subscription once for each template, which can be tedious especially if you decide to change the selection criteria later, as well as the unnecessary rules that are created in the database.

Workflows allow you to choose multiple recipients, each with their own notification template.


For example: you can create a workflow, that when an incident is created, send a notification to ‘Affected User’ using ‘Notification Template A’, and also send a notification to ‘Assigned To User’ using ‘Notification Template B’, all with the same trigger.


The benefit is that way you can customize your notification templates to be much more personal to the recipient, thus including something like “Dear Affected User’.


And I think that sums it up. Will keep you guys posted in case I find any more differences 🙂

How To: Create SCSM 2012 Relationship Subscriptions for Email Notifications


I ran across something during a SCSM 2012 implementation, thought someone else might find use for it.

For some reason, there is no way to create notification subscriptions that are triggered when the “Assigned To User” of a work item changes from the GUI.

After some digging around I found out that this feature is indeed available in SCSM, just not from the GUI, so you are going to have to do some XML editing.

So here is the simplest way I could do this…

First let’s focus on what information do we need to collect to be able to make this work.
1- The name of the relationship you are trying to subscribe to. (For example: Assigned To User)
2- The name of the source class, which is basically your work item that you want this to apply to (For example: Activity)
3- The name of the target class, which in our case is what kind class do you expect to be on the other end of this relationship (For example: User)

Now the actual values in XML might vary from one environment to another, this is why I cannot just upload a MP that does that for you. So here are the steps to do this on your environment.

1- Go to the ‘Administration’ pane, expand ‘Notifications’, and click on ‘Templates’, and have a notification template ready, because once you do this you will not be able to change the notification template for the subscription.


2- Go to the ‘Administration’ pane, expand ‘Notifications’, and click on ‘Subscriptions’, and click on ‘Create Subscription’ on the ‘Tasks’ pane. And create a new subscription for the ‘Manual Activity’ class. And specify the ‘When to Notify’ as ‘When an object of the selected class is updated’.


Note: Make sure you create a new Management Pack specifically for Relationship Subscriptions; preferably one for each, because it will later be easier to track down and update.

3- On the ‘Additional Criteria’ tab, Set ‘Changed From’ condition to anything. Just pick anything like ‘Status’ equals ‘Pending’ for example. This will later be replaced manually, but we need it to get a hold of the source class (Activity) in the XML.


4- Now go ahead an press ‘Next’, and choose the notification template you created earlier. And keep pressing ‘Next’ will you get to the ‘Related Recipient’ tab.

Now in our case, the source class is the ‘Activity’ itself. The target class is the a ‘User’. And the relationship class is the ‘Assigned To User’.

So I will choose to create just one ‘Related Recipient’ as follows:


Note: Why did I choose this recipient specifically, because it has a reference to the relationship and target classes that I need. Had I needed a different target class for example that does not happen to be a user, I would have had to create another related recipient specifically for that. All I actually care about here is getting the references of these objects in the XML.

5- Now don’t forget to add any other recipients you actually need to notify 🙂 because like the template you chose, those cannot be changed later as well. Unless of coarse with more manual editing.

6- Now after you are done with the subscription, simple go the ‘Administration’ pane, and click on ‘Management Packs’ then export the Management Pack you have saved this newly created subscription in.

7- Open the XML file you just exported with any text editor. Now let’s collect our class references from it before we start modifying.

Search for the following text in your XML:

<WorkflowArrayParameter Name="PrimaryUserRelationships" Type="string">

The following lines are the ‘Related Recipients’ you have chosen in the wizard. Now from these lines, extract the class references for your relationship and target classes.
For example:
My Relationship Class: CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser
My Target Class: CustomSystem_Library!System.User

Great! you delete whatever ‘Related Recipients’ you do not need from the XML. And leave the others intact.

8- Now search the XML again for this portion:

<InstanceSubscription Type="7ac62bd4-8fce-a150-3b40-16a39a61383d">
		  <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']/Status$</Property>

Note the name of the source class, for example mine is:

Then, replace this whole portion with the following:

<RelationshipSubscription RelType="$MPElement[Name='CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']$" TargetType="$MPElement[Name='CustomSystem_Library!System.User']$">
  <AddRelationship />

Now note that I have put my relationship, source and target class references that I have collected in the little snippet as shown.

9- Finally, go to the top of the XML file, and increment the version number of this Management Pack inside the tag, this is a best practice but it won’t really matter.

10- Re-import the Management Pack to your service manager, and you are done! 🙂 Now whenever the ‘Assigned To User’ within any ‘Activity’ is changed, the ‘Assigned To User’ should get a notification email based upon your template.

Till next time 🙂