Scenario- Do to the instability and unfriendliness user interface with SMPortal, the customer has decided to create InfoPath forms within SharePoint as the point of contact for self-service. SMPortal could easily facilitate this requirement, but unfortunately there is zero customization that can be performed within the Silverlight portion of the portal, that is outside of SCSM. On top of the lack of customization we cannot consistently get the “My Requests” section to display, end users randomly receive a blank page. Here are the main limitations of the portal that to my knowledge cannot be modified. If someone knows a way to modify these portions, Please SHARE!
Bypass / Skip “Go to Request Form”
My Requests Blank (Yes we opened a ticket with MS and the fix reduces the frequency of this error but it still occurs!)-
Environment- SCSM 2012R2, SCORCH 2012R2, SharePoint 2010, Server 2012 nonR2, InfoPath Lists already created
How to-
After you have created a InfoPath form to a list or form library from SP/InfoPath take note of the SharePoint URL location. We will use this location when defining where to pull from within SCORCH. Also keep in mind when creating this form you have a limitation of fields. There has to be a relationship with where you are going to input these fields within Service Manager. We will go into detail next of where the export of the data relationship exists. Below is an example InfoPath form I have created and pre populated with data.
Figure 1
First we will have to create Incident, Change, or Service Request Template within Service Manager.
Figure 2
Figure 3
Now you can pre-populate this template with information that is not going to come over from the InfoPath form/SCORCH. Remember the field limitation in this template. You cannot populate fields that do not have relationships here, so keep this in mind when creating the InfoPath list. Also if you are using a value within your form such as “Help Desk” you have to make sure the value is the same as its destination in SCSM. If you create a list in InfoPath and have the end user select HelpDesk instead of Help Desk as defined in SCSM, the form will error within orchestrator.
Figure 4
Now let’s do some basic SCORCH magic. First we need to setup your SharePoint connector. Please keep in mind there is a bug with the 3rd party codeplex IP with SCORCH 2012 Sp1. This bug is fixed in the MS provided IP in Orchestrator 2012 R2.
Figure 5
Figure 6
Now you have to make sure the SCORCH account you specify here has permission to the location of the SharePoint list defined in step 1. To do this I logged onto the SCORCH server with the service account I have running the runbook and copied the InfoPath URL and browsed to its location. If you are having permissions issues the runbook will fail with a 401 error. If you cannot get around this leave a comment and ill go into detail on how I permissioned my SCORCH service account.
Figure 7 view of the simple runbook we are creating. Make sure to link in this order or your data wont feed correctly. Ignore the “Run.Net Script” for this guide.
Select your SharePoint configuration setting you defined earlier-
Figure 8
Now you should be able to select the SP/InfoPath list you created (I chose to create an incident)
Figure 9
Now we are going to select the “Create Incident with Template” activity. It is not clear why Incident and Change are the only two MS included out of the box. We use Service Request more than Change/Incident combined so we will need to do “Create Object” with some powershell magic when we get to Service Request (but that’s another topic for another day).
Figure 10
Select your Service Manager connection, and after that you should be able to select your template you defined earlier.
Figure 11
Now here is where you define where to pull and input your data from the SharePoint/InfoPath form to Service Manager.
I want to feed the “Title” in SCSM with “Type” from the InfoPath form. See field “Title” in below. Also make sure you define ID with the value “IR{0}” or you will get ticket incident tickets missing IR as described in my other post https://scjoe.wordpress.com/2014/01/09/orchestrator-scorch-dropping-the-ticket-type-prefix-id-when-creating-an-incident-or-change-to-template-in-service-manager-scsm/.
Figure 12
Now let’s see how we did
I input my test ticket into the form then upload-
Figure 13
I see the form is saved to the SharePoint location
Figure 14
I see my values in form view
Figure 15
Orchestrator works it magic behind the scenes and I now have a newly created IR with the values I entered in the InfoPath Form
Figure 16
Notice some of the values are empty or not defined. You can define these in the earlier steps. Now if you wish to take this further you can expand the form and add extra fields. The Service Request offering we currently use has 10 additional fields available so the InfoPath form can certainly take advantage of the additional fields. This process can be heavily expanded. We can add e-mail notifications, Affected User, Attachments, etc. I will followup with these additional features in later posts, but wanted to give a basic InfoPath-SharePoint-SCORCH-SCSM overview.
-End of line
Thanks for the detailed writeup – I’m tackling this same problem. How did you go about permissioning your SCORCH service account? Thanks again for all of the effort put into this posting!
Thanks for the positive feedback Paul. Admin on everything. It may be overkill but it works 🙂
Site Administrator on SharePoint
Full Administrator SCSM
Local Admin on the Orchestrator performing the Runbook
Also I have noticed the more we add runbooks the more and more we are inching closer to making the Orchestrator Service account a Domain Administrator. Our Orchestrator runbooks do everything from create AD accounts, to clear diskspace on SQL database servers. Security Pro’s like to break each up each individual runbook and function with a different service account but that’s really unrealistic and will cause so much more work! Good luck.