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.

image

image

image

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.

image

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.

image

Give the activity a name and select a management pack.

image

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

image

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.

image

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

image 

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.

image

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.

image

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.

image

image

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….

image

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.

image

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.

Comments (0)

Skip to main content