Handling Many Service Request Inputs

Some work I did for a customer recently involved the automation of their new user creation process. Previously they had been using a Word document which was filled out and emailed to the respective groups for them to complete their part of the process. The goal was to have the HR person enter the information in the self service portal. During an initial interview we identified nearly 30 fields which needed to be filled in – no problem I though until it came time to build the Runbook automation activities in Service Manager.

The problem lies in how many types of input you can have for each data type including only 4 Boolean values per Runbook activity. As my process required seven true/false values I needed to find a way to read in all the inputs and allow all the values to be mapped.

What I did was create two Runbooks – these would absorb all the values in the service request. For the demo I have created 2 simple Runbooks to demonstrator how I can read in 8 Boolean values.

The first Runbook simply contains an Initialize Data activity which provides a place for me to map four of the Boolean inputs. I’m not going to do any processing in this Runbook – it is just a soaker for the automation activity. The second activity updates the Runbook Automation Activity in Service Manager and marks it as complete so the next activity can launch. I do this because I don’t want to wait for the workflow to run in Service Manager.

The second Runbook has a couple more activities. I use my Get SR GUID Runbook to map the Runbook automation activity GUID to the service request GUID. I need this so I can access the user input field from the service request. I have a Get Object activity which retrieves the service request object for me. The user input field is written out to a platform event so I can see what is contained in there. Finally I update the automation activity as in the previous step.

As in the first Runbook the Initialize Data activity simply is a placeholder for another four Boolean values. Now check in the Runbooks and perform a synchronisation of the connector in Service Manager.

I can now create my Runbook Automation activities for the new Runbooks – highlight the Runbook in the Service Manager library and click Create Runbook Automation Activity Template.

Give the activity a name and select a management pack.

Fill in the title (makes it easier to read later) and select Is Ready for Automation. Then select the Runbook tab.

What we need to do in this screen is change all the parameter mappings. I go to each mapping and click Edit –> then select a Boolean value to map my response to. You can see there are only four allowed in the activity – again this is the whole reason for having two Runbooks – to get over this shortcoming.

The Runbook GUID parameter I map to the Id value of the Object as below.

 

Once all parameters are mapped – save the activity and complete the same steps for the second Runbook. What you have after this is two activities we can add to a service request. They will then be activated in order when the service request is created. I create a new service request and add my two activities to it. First activity calls Runbook 1 and the second calls Runbook 2.

Now I can create the Request Offering. Select the template you just created for the new offering. Create 8 Boolean inputs in the User Prompts section. Change the type to True / False for each one.

In the Map Prompts section – map each prompt to a Runbook activity prompt. Ideally if you were doing this in real life you would call them something more useful. After this is done you can skip through the rest of the wizard – publish the request offering though.

Finally to test – in the self service portal my inputs are presented as in the image below. A bit messy but maybe I can fix it up later….

Once I hit Submit – it will create the Service Request and launch the first Runbook. This will straight away update the activity and set it to complete so the other task starts. The second task finds the service request GUID and writes out the user input field to a platform event so I can see what is in there.

We can use this data to get the values for any question in the original service request. I will cover 2 ways to do this in a separate post.