It’s not always required to have a Review Activity or Manual Activity for a Service Request but you might have noticed that if you don’t have those then the complete button can take some time to appear for the technician to close the Service Request. When your techs are on the phones constantly and working multiple sessions this can become an annoyance. All they want to do is track the call in the ticket and move on. How about allowing them to track that call, save the ticket and move on to the next and have that ticket close itself?
Lets pull some Orchestrator into the mix to speed things along. This will also utilize what I like to call a runtime database to store info from the data-bus so we can retrieve what we need instead of being at the mercy of what Orchestrator thinks we need. I use this in several of my runbooks to great advantage and once you start utilizing a runtime DB you will have a hard time going back. Lets take a look at a birds eye view of the runbook.
To start off with, you will need to create a Service Request template and call it something like Default SR as Resolved or whatever you want. You will need to add a runbook activity to the SR template that will start the process. Now when a tech is working these tickets they just want to capture the reason for the call and maybe the steps they took to resolve the call. They don’t want to have to click around on different tabs and fill out the resolution comment or the results. Too much time in an overworked helpdesk, so what we want to do is grab their last comment and send that to the user in the resolution email and set the necessary fields for reporting. So lets break this down.
In the Initialize Data we are just sending the Runbook Activity GUID. In order to do this we want to map the Object ID to the parameter mappings field in the runbook activity that is part of the Service Request.
Easy enough. Now we need to find the relationship from the RBA to the SR. That is what these three IPs are doing.
The Get RBA Object is retrieving the RBA from the Service Request.
The Get Parent SR Related to RBAID IP is finding the relationship.
And now we are getting the actual SR that we need using the Get Parent SR IP or Get Object as it’s referred to in the activities.
Next we want to grab the analyst comments from the ticket so we need to find the relationship of those to the SR.
Now that we have the relationship lets grab those comments.
Now if you have some techs that are eager to please and like to capture multiple comments in the ticket then that is where the runtime db comes into play. With orchestrator, as you know, if multiple results are returned then however many results are returned, that is how many times the next IP is going to trigger. The comments are grabbed in order of last to first comment so that means the last comment will be written to the results field then overwritten by the first comment. We don’t want that. So lets turn to the runtime database so we can manipulate that data the way we see fit.
What I did was create a second DB on the Orchestrator DB server and I create new tables as needed for each project. This creates very little load on the DB server so I’m not worried about the Orchestrator DB having issues keeping up but if you prefer you can have a new server handling this DB. I’ve called my DB SCORCH_Runtime. I created a table called dbo.AnalystComments in this DB with the following columns:
The CommentOrder column increments by one automatically. This column is setup as Identity = True, Identity Seed = 1 and Identity Increment = 1. This will allow us to know exactly which comment we need to pull since we know comments are pulled from last to first.
Now we need to write these comments to the DB. We also need to capture the SR ID so we grab the right comments. We don’t want to confuse the users with unrelated comments.
We don’t want to query the DB multiple times if there are multiple comments on the ticket so we are going to incorporate a junction into the mix.
Now we need to query the database and get that latest comment so that is what the user will receive in the closure email.
Now lets update the SR and take care of business
And the Update Activity IP so we don’t have to wait on SCSM’s workflows to close out the process.
And there we go, first call resolution at its easiest, for the analyst that is. Let me know if you have any questions. Have fun!