Solution to clean User Input from Service Manager Portal and commit it to the Action Log

This solution converts end-user userinput from Service Manager Portal into a clean formated string table and commits it to a new Action Log entry in top. The script can be modified for other purposes: e.g. used in Orchestrator or appended to the description field.

I made this powershell workflow script because of different wishes from customers all related to complains about the user input on the Service Manager Portal:


  • End-Users can’t see what they typed on a request offering in the service manager portal.
  • Even if the formular only contains limited questions (e.g. Title and Description) the description field on the portal can only show 3 rows (yes, it’s true Smile).
  • The User Input on a Service Request can be hard to read for the analysts as it is printed out in XML (the below happens if you want to display Config Items on the portal via Query Result option):


  • The User Input on a Incident is not shown at all! The inputs are mapped to the incident form, but could be mapped to different places and might be hard to find. Although Anders Bengtsson made a solution to come to grips with this( it doesn’t account for the xml printout and the End-user still can’t see his/her user input. Allthough, you could probably use a combination of this and my solution here.


So, to solve this for both end-users and analysts I decided to commit the user input to the action log instead. And at the same time clean the user input to handle config items and enumerations. This way the end-user are able to read all his/her previous answers and the Analyst can also view the user input on the General panel in the top of the Action Log.


Ok so here is what happens:

1) The end-user makes a new Request from the Service Manager Portal (either Incident or Service Request):


2) A workflow with a powershell script runs that triggers on Work Item created where User Input is not empty (this way we can get both Incidents and Service Requests and reasure it’s coming from the portal). The script then cleans the user input into a formated string table and commits it as a new actionlog entry.

3) How the Analysts see it:

Service Request:




4) How the End-User see it:


As a bonus you can also see the related request offering which makes it a little easier for analysts to quickly recognize the type of request.


  • SMlets installed on the SCSM Management Server (workflow server) :
  • Service Manager 2012 SP1 with UR2 or later (version numbers in references could be modified to support older versions, but it’s not tested on these. Just write to me if you want a version compatible with older versions)


Download from techned gallery here:

The zip file contains the following:

  1. Coretech.PSWorkflow.SetUserInputToActionLog.xml : The unsealed Management Pack that contains the workflow (feel free to seal it if you want)
  2. PSWorkflow_SetUserInputToActionLog.dll  : Assembly dll file
  3. SetUserInputToActionLog.ps1 : Script file if you want to check it out or reuse elsewhere.

Installation instructions:

  1. Copy PSWorkflow_SetUserInputToActionLog.dll  to your Service Manager install folder, e.g. C:\Program Files\Microsoft System Center 2012\Service Manager
  2. Import the Management Pack Coretech.PSWorkflow.SetUserInputToActionLog.xml
  3. Enjoy!

If you have any feedback on this, just throw a comment or write me an email.

The solution is provided “as-is.” You bear the risk of using it.

Comments (17):

  1. Anders says:

    How much of an impact does this additional workflow have on performance? Ie. any experience with deploying this on systems with 100′s of new incident and service requests each day?

  2. Morten Meisler Morten says:

    Good question. I’ve not done any stress testing yet, but I will do so when I can and report back. The script itself is measured to complete the first time in 13 seconds and subsequent times for 300ms. I’m not sure if the procedures are cached when it runs the script through a workflow though, but I’ll investigate further when I got time.

    • Morten Meisler Morten says:

      The measure was tested on a VM test-server with Win2008R2, 8gb ram, 4 cores, non-ssd. So it’ll probably run faster in a prod environment. But will report back asap

  3. Morten Meisler Morten says:

    I’ve done some stress testing now and observed the running time and if any workflows falling behind (Travis’ sql query)

    Making 20 incident and service requests within 5 minutes on the portal did not seem like a problem. The only workflows falling a little behind (5-7minutes) were the notification workflows sent to affected user. But it did that as well without this script.

    But there is an error logging to the Operations Manager event log on the server if something goes wrong (eventid 912). I’ll be happy to get the output from that if errors occurs.

  4. Kenneth Andersen says:

    Hello, I like the “workaround” :-)

    But can I get the workflow to run then iam using the Exchange Connector ? So that the first e-mail description is loaded to the action log?

  5. Morten Meisler Morten says:

    Well the script only takes care of userinput, so you’d have to modify it to grab the description property instead and commit that to the action log description. The rule could then be set to Incident Created where source = E-mail.

  6. […] blog: Solution to clean User Input from Service Manager Portal and commit it to the Action Log @ Coretech […]

  7. Isn’t it best practice to do workflows in Orchestrator (or SMA), and not in the builtin workflow engine?

    og nu ;)

  8. Morten Meisler Morten says:

    As I wrote in the top, you are welcome to use the script within a runbook. Not all people have Orchestrator though. I’m not sure why it would be bad practice to use the workflow engine, it’s there to be used. I suppose you might as well “outsource” all your workflows (notifications, group changes etc.) if that were true.

  9. Vincent says:

    Thanks for this MP. The action is log created, but the MP status still shows that it fails in the last activity:

    System.TimeoutException: The operation has timed out.
    at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTaskInternal[T](IEnumerable`1 targets, Guid taskId, TaskConfiguration configuration)
    at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTask[T](IEnumerable`1 targets, ManagementPackTask task, TaskConfiguration configuration)
    at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.TaskExecutor.RunTask(String sdkServerName, Guid taskId, IList`1 taskTargetIds, Dictionary`2 taskArguments, Int32 taskTimeout)
    at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.RunTaskActivity.Execute(ActivityExecutionContext executionContext)
    at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)
    at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
    at System.Workflow.Runtime.Scheduler.Run()

    Would you please have any idea? NB: I am using SCSM 2012 R2.
    Thanks. Vincent.

    • Morten Meisler Morten says:

      Hi Vincent,

      Thanks for using the MP, I have not seen that before. But it looks like the workflow times out for some reason. It has a timeout set to 600 = 10 minutes. You can change this in the MP, but it should be more than enough though. So I need some more info to help:

      Does it do it for all kinds of Request Offerings?
      Can you show / describe the request offering(s) it does the error for?
      Is there any errors created in the event log? Search in the Operations Manager log after eventID 912. If the script made an error it should be there.

  10. Vincent says:

    Hi Morten, could you please drop me an email, so that I can reply to you with screenshots? Thanks. Vincent.

  11. Vincent says:

    Hi Morten, the user input entry is immediately created in the action log, but somehow it hangs somewhere and times out. the MP fails for both IR and SR. No event ID 912 in the event viewer.
    In the workflow status, I can see:
    – Event 3: PSWorkflow_SetUserInputToActionLog is executing
    – Event 4: windowsPowerShellScript1_SetUserInputToActionLog is executing
    – Event 9: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is executing
    – Event 12: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is faulting
    Thanks for your help.

  12. Morten Meisler Morten says:

    Hi Vincent,

    Could you send your request offering in the management pack, then I can try to troubleshoot further. Just send it to: mme at coretech dk. Screenshots/descriptions of your request offering is also ok, but the mp is most optimal. Also what language is your management server set to?

  13. Tom says:

    Was a solution ever found for Vincent’s problem? It appears I am having the same one.


  14. Morten Meisler Morten says:

    Hi Tom, we concluded it was some form of security issue. Try unblocking the dll file in the install folder (if it’s blocked). I got vincents RO and it worked on my setup. So I couldnt replicate the error. I recall it was no issue anyway as it ran fine, so the workflows error could be ignored, but not optimal of course.

    Please let me know if the dll thing works, if not Ill try to see if I can provoke the error in some way.

  15. Tom says:

    That security problem appears to have been resolved by unblocking the DLL. The workflow still says it’s failing but runs mostly fine. I say mostly because it looks like only the first of how ever many fields is being grabbed and then the User Input item in the action log only says “Undefined.”

    We are trying to set this up with Incidents and I have extended the class to add extra text fields to map the user inputs to.


Leave a Reply