A while ago, I have blogged on how to leverage the userinput stored (tipycally) in a Service Request from Orchestrator, to avoid too many class customizations. Very often, customers want all the Userinput to be stored in the Description or Notes field of a Service Request. I used to do that in Orchestrator as well. For sake of learning and practical usage, I have decided to use basically the same script and create an SCSM workflow to allow for the Description (or another custom field) to be populated with the contents from the User input.
Let’s take a look at how things work.
First of all, the core of the solution. To implement it, you will need a few things:
– Create a new class extension of the Service Request class in the Authoring Tool;
– Create a workflow to be executed whenever the Service Request status changes to In Progress
Creating the class extension
In the Authoring Tool, extend the service request class and add these two properties:
In this case, I have decided to add a second (extended) description field but the existing Description field can be used as well.
Update: I have added a second control field, in order to make sure that I would only notify when the description (or extended description) had been updated:
Now my extended class looks like this:
The default value for UserInputProcessed is false:
Create a workflow for the Service Request class:
Drag a powershell activity:
Into the new WF:
In the script parameters, add ItemID:
And link it:
Now for the script you download it here. You will open the file and paste it here:
Important Note: this scripts uses both the SCSM 2012 cmdlets and the famous SMLets.
The latter should be installed. You may want to reboot you server just so the powershell modules can recognize the new CMDlets.
Once you have it there, all you need to do is create a new template for the Service Request and set whether you want the workflow run the script or not:
Apply this template to a new Request Offering, put in a request and once it has been processed, you should see the contents of the user input transported into the ExtendedDescription field.
For my testing, I have created a Request Offering with most of the possible field types:
And here is the content:
In order to properly notify, use a notification subscription as below:
Hope this helps!