Add User Input to Description Field for Incidents from the Portal


Have you ever noticed that Service Requests have the user input from the portal on the front of the ticket but Incidents don’t.  If you’re like most users of SCSM you have probably extended the incident or service request class with some generic fields so you can ask more questions on the portal and have fields to map to, if not I’ll save that for another post.

We are going to use a little Orchestrator and Powershell magic for this.  First you will need to add a Runbook activity to the incident template you will be using for portal incidents.  Here is a birds eye view of the runbook and we will go over each IP individually.

 

Parse User Input

We are going to start with the initialize data IP.  You are just going to pass the Runbook Activity ID into the initialize data IP.  I’m going off the assumption you already know how to trigger a runbook from SCSM but if not leave a comment and I will go further into detail.  We are going to pass that RB ID into the Get RBA Object IP as so.Get RBA

Now we need to get the relationship of the Runbook Activity to the incident.

Ralated

As you can see, I am using Extension of Incident Related Class because that is what I called my class when I extended it.  FYI, I extended it to 30 generic text fields and 2 generic date time fields for growth and for those of you that where wondering.  These fields can be seen on the extension tab of the incident ticket but nobody wants to click over there to see the info and they are generic fields so the labels are meaningless to techs.

Now lets get the IR

Get IR

When you are choosing the value make sure to use RELATED OBJECT GUID not Relationship Object GUID.  Relationship will get you nowhere in this scenario.

Now here comes the PowerShell magic.  Parse User Input into Array.  You will use the Run .Net IP here and choose Powershell as Type.  Your details tab will look as so

Run .Net

and your Published Data tab will look as soPublished Data

And here is the magic code to pull it all together

$UserInput= ‘{User Input from “Get IR”}’
$nl = [Environment]::NewLine
$content=[XML]$UserInput
$inputs = $content.UserInputs.UserInput
foreach ($input in $inputs)
{
if($($input.Answer) -like “<value*”)
{
[xml]$answer = $input.answer
foreach($value in $($($answer.values)))
{
foreach($item in $value)
{
foreach ($txt in $($item.value))
{
$ListArray += $($txt.DisplayName)
}
$Array += $input.Question + ” = ” + [string]::Join(” ; “,$ListArray) +$nl
$ListArray = $null
}
}
}
else
{
if ($input.type -eq “enum”)
{
$ListGuid = Get-SCSMEnumeration -Id $input.Answer
$Array += $($input.Question + ” = ” + $ListGuid.displayname) +$nl
}
else
{
$Array += $($input.Question + ” = ” + $input.Answer) +$nl
}
}
}
$Array

{User Input from “Get IR”} will be replaced with the variable of the same name from the Get IR IP.  Make sure to leave it in the single quotes.

Next we will pass the $Array variable into the Update Description IP mapped to the description field of the incident.

Update Description

And for good measure we will update the Runbook Activity to complete so we dont have to wait for the SCSM workflows to do it for us.  Just makes things a little quicker.  Update Activity

Just remember when creating a IR for the Portal don’t map anything to the description field.  Map everything to the generic fields unless it pertains to a specific field like priority then map that to priority.  I think you get the jist.  If done correctly you will get something like this.

Description

There is also an additional comments piece below the transaction date but as you know the incident description field only scrolls and doesn’t expand like the SR description field does.  That is a post for another day. But alas, viola, there you have it.  All the information your tech needs right in the description field.

Advertisements

48 thoughts on “Add User Input to Description Field for Incidents from the Portal

  1. Sharon

    I’m looking for more details information on ‘We are going to start with the initialize data IP. You are just going to pass the Runbook Activity ID into the intialize data IP. I’m going off the assumption you already know how to trigger a runbook from SCSM but if not leave a comment and I will go further into detail.’ this step.

    Like

    1. On the Initialize Data IP you will need to add a variable in there called something like RBAID. It doesnt matter what you call it as long as you know what it means. Check in the runbook and run the orchestrator connector in service manager. Once the connector finishes verify that the runbook was synced into scsm by clicking on libraries and then runbooks. If you see it then your good. Now go to templates and create a runbook automation activity template called something like add user input to description. Check the box ready for automation and then click the runbook tab next to general. Hit the select button and choose the runbook that you just synced. Under parameter mappings you should now see the name of the variable that you put in the initialize data ip show up. Click the edit mappings button and choose object\ID as the mapping. Hit close and save. Now any incident template you create for the portal just make sure to add that runbook automation template to the activities section and every incident created from the portal using that template will automatically add the user input into the description,

      Like

      1. Sharon

        Thanks for this Jeff, appreciate your quick reply. I think I’ve followed all the steps.

        When I create the incident request offering based on the incident template with my RBA listed under activities I put a few random questions in the user prompt section, proceed through … configure prompts, map prompts (I don’t do anything here, but the RBA is listed in the map objects no properties under it)… at completion it tells me I have to map my questions, it won’t proceed.

        I’m not sure where I’ve gone wrong.

        Like

  2. All questions have to be mapped to a field. You need to extend the incident class using the Authoring tool. In my environment I’ve added 30 generic text fields and 2 Generic date fields to the incident class so Im not limited to how many questions I can ask on the portal (up to 30 at least but if you have that many questions on your portal request the user will probably give up anyways). These fields will show up on the extensions tab of the incident ticket. That is where you will map the portal questions to. If you are not familiar with extending classes let me know and I will write up a blog post about that. It’s pretty simple to accomplish. The Authoring tool can be found here https://www.microsoft.com/en-us/download/details.aspx?id=40896

    Like

    1. Sharon

      Thanks Jeff, again appreciate your prompt reply.
      I re-read carefully (not skimming) and just worked that out myself… should have waited 5 extra minutes before I emailed you
      !

      Like

  3. Sharon

    Hi Jeff, its going great. My initial tests are passing the basic text fields to my incident description field. Yeah! . I’m assuming that you can use list fields too? Right?

    Like

  4. Sharon

    Thanks for all your help with this, I have it up and running. Its working great.

    It would be wonderful to have an option to append one of the questions and user input to the title field. If I map it, it put the users input but not the question. Is there a quick easy solution for this.

    Like

  5. Sharon

    Is there a way to just append 1 line of the text (question & answer) to the title field also?
    I can map that question to the title field, but it only appends the answer, or overrides anything that I might already have there.

    Like

    1. If you want to append then you need to use get item to get the title you put in the template then add a – then the vaiable from the custom field that you want to add to the title. If you want to just add the question and answer to the title you will most likely need to rewrite the powershell script that is doing the formatting. I just started a new job at MS so it will be a bit before i can take a look.

      Like

    2. Hi Sharon,
      I didn’t really have time to rewrite the PS script and since the script isn’t a true array it’s a little more difficult to manipulate the data. I’m sure it’s possible but I’m still learning PS myself so I just used Orchestrator to manipulate the data. Make sure what you want in the title is populated in the custom field 1. You can change the Format Answers IP to suit your needs. I tested this with 3 inputs with input 1 going into the title and input 2 and 3 going into the description. Here is the link to the update RB. https://onedrive.live.com/redir?resid=7DC7416B6822262D!127&authkey=!AKG8IYKvG5iT994&ithint=file%2cois_export

      Like

      1. Sharon

        Hey jeff , sorry I posted this message and it didn’t show up on comments so I thought I’d done something wrong so I reposted (you replied the other day) . My apologies, no pressure all your help is much appreciated. Thanks again good luck with your new job.

        Like

  6. Sharon

    Hi Jeff. We had a bit of accident, one of our network admins accidently deleted my runbook. We’ve tried restored it from back up and tried recreating it and the RBA (its enabled for automation) from scratch.

    The runbooks (restored and new) are there and sync to SCSM as active. I’ve updated the request offering with new RBA.

    But when the job comes in it just creates a RBA and its stuck in process. No log on the RBA to with error or fail.

    We’ve rebooted servers…. I’m lost as to why its creating the RBA for the incoming job, but not envoking it, any pointers to what I’m missing?
    VERY, VERY MUCH APPRECIATED
    Thanks advance

    Like

    1. I don’t understand what you mean by its creating the RBA for the incoming job. The RBA should be hard coded to the template. Make sure the RBA on the service request under the Run book tab that your newly created run book is listed in the name section. If not. Delete that RBA from the SR template and create a new RBA and add that to the SR template activity.

      Like

  7. Sharon

    Hi Jeff – I’m sorry if I was a bit vague it was a long day. I’m actually using Incident request in this scenario below.

    Runbook: Original runbook restored from back up and sync with SCSM (runbook active in SCSM)

    Runbook Automation Activity: Removed previous RBA. Created new RBA linked user input runbook, set parameter mapping to object/id. RBAID from initialize data is displayed.

    Request Offering template: Link new RBA to Incident request offering template on activities tab. Update portal.

    Portal Request: User submits portal request. After submission, under Runbook automation activities (all activities) there is an instance created for the RB, with parent workitem linked. Status remains in progress with no log messages and user input is not transferred to description field. Submitted data is on the extensions tab.

    Previously it would transfer the data, and there would be log entries in runbook automation activity such as invoking runbook, parameter values and sucessfully invoked.

    There is nothing now. I’m lost to as what I’ve missed or what is not running that should be.

    Like

    1. Is this incident ticket moving from new to in progress for the status? Try deleting the runbook from the scsm console (not from orchestrator) and re-sync using the connector. Make sure the ready for automation box is checked on the RBA. Recreate the RBA and add it back to the incident template. If the incident ticket status is not moving to in progress then you have another issue. Let me know.

      Like

  8. Sharon

    The delete option is greyed out on the SCSM console when I select the runbook. I can only remove missing runbooks.

    Something else I noticed in the runbook automation activities that are generated when the user submits the job is the SCOjob identifier is empty, where as the previously completed jobs it has a number (GUILD I’m guessing). Is this not the orch job number?

    Like

    1. The SCOjob identifier will be empty until the runbook is invoked. Is there any information in the history tab of the RBA that is created when the incident is submitted? Can you post some of that info?

      Like

    1. Ok, nothing looks out of the ordinary. Just to verify that the runbook still functions properly, take the guid that is in the parameter mapping field of an in progress RBA and put the runbook in debug mode and plug that guid into the runbook manually. you probably will have to type the guid manually since its greyed out and not in the log. let the runbook do its thing and check the incident to see if the fields where mapped. if that works then you have an issue between SCSM and SCORCH. I would export the runbook and delete it out of SCORCH and run the orchestrator connector in SCSM. it should say missing now. Delete the runbook in SCSM. Import the runbook back into orchestrator and run the connector to resync. Rebuild the RBA and re-attach the RBA template to the incident template and submit a ticket as normal

      Like

      1. Also, when you rerun the connector to get the runbook back into SCSM, if it doesnt show up dont panic. just run this query against the orchestrator database and rerun the connector. TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache

        Like

  9. Sharon

    Ok, so I have not removed anything yet. thought I’d start with debugging.
    Debugging worked. Everything passed and user input was copied to description field.
    So I have an issue between SCSM and SCORCH… that further than I was.
    Any ideas, where to start now. 🙂

    Like

    1. I would export the runbook from orchestrator and delete it and follow the rest of the instructions. I’m not sure how you restored it initially but that could have caused the problem. Reimporting will allow all the guide to be rewritten and give you a fresh start

      Like

  10. Sharon

    Same outcome 😦
    It remains in progress until you debug and then it processes.
    Crazy! Seems like SCORCH is talking to SCSM, but not the other way.

    SCORCH is talking to our other servicers – SCCCM, we have a a few RB working with config man.

    Like

  11. Sharon

    Jeff, thanks for your help so far. Its Friday after 5pm in Australia…. I think I’m going to forget about this for the weekend. Enjoy your weekend.

    Like

    1. I deleted the url to the logs that you posted, that really should be shared securely. A lot of info about your domain in there. 🙂 I did take a look and i can see the runbook was deleted on the 11th or 12th for you since im in the central time zone. I also noticed that it looks like you might be using the Cireson portal? I want to make a couple more suggestions then I will have to suggest you open a support ticket with Microsoft since this could be a conflict of interest for me.

      1. Try creating the incident from the console instead of the portal. Put the test text in the boxes they would normally go in if the incident was created from the portal. Does the runbook trigger when the incident is created from the console? If so then your portal cache is stale and needs to be flushed. If you are using the Cireson portal run this against the Service Management DB (that is Ciresons DB) not the Service Manger DB (that is the SCSM DB)
      TRUNCATE TABLE LastModified;
      TRUNCATE TABLE ServiceOffering;
      TRUNCATE TABLE RequestOffering;
      Restart the cireson cache builder service on the portal server. Do this during off hours. This will make all of your service offerings and request offerings disappear for a brief amount of time as the cache is rebuilt. If creating the ticket from the console did not trigger the runbook then:

      2. Under Administration\Workflows\Status check for workflows that are related to Activity or Orchestrator and see if any need attention. These can help identify your issue

      I would love to dig deeper into this but i dont want to cross any lines. I would like to know the resolution if you do open a support ticket with MS

      Like

  12. Nathan Bates

    Jeff, I hope that I am not attempting to open up a topic that is too old. I have just started to work with Runbooks and Orchestrator integrating into SCSM. I am using your runbook posted here as a template for the one that I am making.
    I am running into an issue when using the runbook tester. On the Get RBA Object after Initialize Data, the tester is throwing an error (Error parsing value [IR55] to type [guid].) I am assuring that I am not initializing the correct data in the previous step( IRNumber as a String).
    Please advise
    Thanks

    Like

    1. Never too old 🙂 It sounds to me like you are using the IR number to start the runbook. You need to use the GUID from the Runbook Activity that is attached to the IR ticket that kicks off the runbook. So in your case, open up IR55 (which is probably in a failed state) and click on the Activities tab. You should see an RB number in the activities box. Double click on that and it will open the RB ticket. Scroll down to log entry and click expand all if its not already expanded. In the parameter values section you will see IRNumber=LONG STRING OF TEXT. That’s the GUID you need to use in the tester. You need that long number and letter string after IRNumber=

      Hope that helps.

      Like

      1. Nathan Bates

        Great! that did the Trick, Have been able to move on debugging the runbook, I am now running into an issue at Get Parent IR Related with the error [SC Object Guid] is null or empty. I have verified that the value are correct for the run book and am now checking the IR. Any advice would be great.

        Thanks again.

        Like

      2. What Object Class are you using? What Related Class are you using? Did you extend the Incident class to capture the additional data on the ticket using the Authoring tool?

        Like

  13. Nathan Bates

    Object Class = Runbook Automation Activity
    Object Guid = SC Object Guid from “Get RBA Object”
    Related Class is Incident ( I did not create an extension of the Incident Class)

    Like

    1. You must extend the Incident class for this to work properly. If you read towards the top of the article you can see I added 30 generic texts fields and 2 generic date fields to my Incident class. If you plan on working with SCSM then you will need to become very familiar with the Authoring tool for SCSM. If you are not the admin for your SCSM implementation then you will need to get with them to extend the Incident Class. If you are not familiar with extending classes in SCSM let me know and I will try to write up an article on how to do that. It will take a lot more explanation then a comment field will allow for but it is very important to know if you want to make SCSM as powerful as it can be.

      Like

      1. Nathan Bates

        I did read that you had extended the incident class, I only assumed that it was not a requirement and that you would be able to use the standard incident class in order to grab the User Input Property.

        I am aware of the Authoring tool and about extending, although only on the surface have only started looking at both Orchestrator and SCSM and working on getting a web support portal up and running to specification. Great potential with both products.

        Like

      2. “Technically” “and I say that with an inflection in my voice :)” you are correct with 2 caveats. First, the incident HAS to be created from the portal because that is where the User Input property comes from so if you dont have the OOB portal setup then you wont get far with this yet and 2, once you have a portal you really only have 2 fields on the incident class you can map to and that’s the Title field and Description field. That really wont be enough fields if you want to ask more the “what’s the issue and describe it”. SCSM has enormous potential especially with Orchestrator in the mix.

        Like

      3. And I should be clear, it doesn’t necessarily have to be the OOB portal, it can be Cireson’s portal as well but again a portal is required to get the User Input property populated.

        Like

  14. Nathan Bates

    Ah you would 100% correct that there are not enough spaces in order to gain additional information, and that extension would be the proper path. I was working to use a portion of your runbook and then use the output in a different manner.

    With the portal(HTML5 SCSM 2016) that I am working on I have a List Object that is specific to the IR type that is pre populated with 3 options for the user to select. I have found that the answer was retained in the User Input Property and was attempting to parse the User Input then set the IR Classification based off of the User Input in order to limit the number of options the user has to select when selecting the “classification”.

    I was attempting to use the example of the runbook you made and instead of Updating the Description use 3 different paths and using the exclude variable to update the classification category based on if the array contained the corresponding user input from the List Variable found on the IR Web Submission.

    I am sure I am just scratching the surface, and if you have suggestion on a better direction to take it would be welcome.

    Like

    1. What you are describing is very much doable and I’ve done something very similar to that already. So just to clarify then, you already have a portal up and running correct? Are you creating the ticket from the portal first then debugging the runbook using the ticket created from the portal? What is your end game for this? Are you trying to use this for ticket routing “hopefully” because the classification should usually be completed by the tech otherwise you are putting a lot of faith in your users? Also, where are you mapping this List object to in the ticket?

      Like

  15. Nathan Bates

    Yes, I do have a fully functional portal up and using the data from the created ticket and attached RBA to feed into the debugger.

    As for endgame, yes it is to allow for better routing as our ticketing system is going to cover multiple departments of our organization and I want to limit the choices the users has, and allow attempt to provide our techs with the most accurate information.

    Currently it is not mapped to any location. The prompt is configured as a simple list and capture as Use Input.

    What I found is that in the History of Property Changes, on the IR, the User Input Field holds the value of the question/answer even though it was not mapped. I have been attempting to look at that field to make the proper assignment.

    Like

    1. Ok, I’m following except for one thing. The Simple List has to be mapped to some property on the ticket or the Create Request Offering wizard wont let you publish the Request Offering to the portal. I just ran a test in my lab using the runbook exactly how its setup mapping the simple list to a generic field, to the title and the description on the IR and it worked as expected, but it had to be mapped to something for it to be published to the portal. You should be able to link filter right after Remove Title from Description. So back to the original problem, if you are getting a error on Get Parent IR Related to the RBA ID then that means Get RBA Object is not returning any values. Step through the debugger and expand the show details and see what data is being returned for Get RBA Object. If its blank then you are using the wrong GUID to start the runbook.

      Like

      1. Nathan Bates

        Jeff,

        Was able to step away from the issue for a little to gather my thoughts and have decided tho reconvene. Forgive me for being dense, but with the extension of then incident class you are not adding anything to the stock form that is view-able. You are simply adding additional properties that can then be manipulated down the road? Please correct me if I am wrong.

        I know that you said that the name does not make a difference when creating, but does data type or value constraints cause any issues?

        Thank you!

        Liked by 1 person

      2. Technically you are correct about the form. Nothing is added to the stock view and can be added to the stock view later down the road but can be manipulated at any time. But, you will notice an extension tab at very the top of the ticket on the left hand side(not with the standard “General, Activities, Related Items” tabs). That is where all extended properties go automatically, so they can be viewed on the ticket, it just takes an extra click to see them.

        On your second question, I believe you are talking about mapping fields? Yes it does make a difference what datatype you use. True,False datatype would require a Boolean extension, Integer can be mapped to a text field but that can cause issues when writing reports and could require additional SQL to convert to a Integer type for any math that is required so integer datatype should be used. In other words, yes there are some constraints. Most of the time you will use a simple text datatype but you should take the time to consider what this data will be used for in reporting and choose the correct datatype to prevent headaches down the road.

        And you’re not being dense by any means, this product is very customizable which is very good but can cause frustrations when you are just stepping into this, but it is well worth the effort. You are stepping into development and nothing is easy about development.

        Like

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