In this post I want to give a simple example how you can use Opalis to save time for your service desk. Often the 1st line do the same tasks over and over again. For example when a user calls in a incident around access to the intranet, service desk connect to the desktop machine, check the same things every time and it is almost every time the same issue. Doing this every day is boring and it is easy that there is a difference between how service desk engineers perform these tasks.

This is where Opalis can help. Instead of resources from your service desk should do these simple tasks, let Opalis do them and then update the incident. Opalis will do it quick and exactly the same every time. If you need to change anything, change the workflow, and Opalis will instant start using the new settings. The following workflow is a example of what you could build to save some time. The next obvious phase would be to add more steps to also fix any problem that Opalis detect.

1. The first activity checks for new incidents in Service Manager with classification category equals Desktop Problem
2. Update the incident status to Opalis. This is to show that Opalis is working on the incident
3. Get related computer, affected item, from the incidents. This is the machine where we will do all tests, as this is the machine the end-user has a problem with.
   
4. Gets the windows computer object with the object GUID that we get from the “get related computer” activity
5. Trigger the first troubleshooting workflow, “ping policy”
6. If the first troubleshooting workflow did not found any issues the next troubleshooting workflow will start, process policy
7. Change the incident status back to the status it had before activity 2 in the workflow

The first troubleshooting workflow is shown below. It will start by simple check if the desktop machine is accessible on the network with a simple ping. the workflow till update the incident with the result and then publish the result on the databus. I trigger the same workflow for both a good and a bad result. There are both disadvantage and advantage with that solution. I can use the same workflow for all my troubleshooting policies and that results in simple workflows. A disadvantage is that I cant add that much custom details to the incident update, for example in this example I will only update the incident action log saying the “ping policy” failed. There will be no info around number of pings that failed. I try to keep number of tests in my troubleshooting workflows to a minimum, so if a workflow fails we know direct what it is. For example instead of testing five processes in the same workflow, I can build multiple workflows with one test in each, then simple update the incident with the incident that failed. As the workflow only test one thing I know what the problem is, and I can use same error logging for all workflows.

The incident update workflow generate a random number that will be used as ID for the action log comment in the incident. From each workflow that trigger it the workflow gets result, policy name of the calling workflow and computer name. These three attributes are used to generate the action log update.

Incident action log updated by Opalis. The header of the action log comment is <Workflow name> <Result>, the comment is <Result> <Workflow name> <Computer name> as shown in the figure above, result below. This makes the update action log workflow easy to use for all workflows, they just need to forward workflow name, computer and incident number.

The second troubleshooting workflow checks a process and a service on the machine, and then updates the incident.

This export file have meet “mr Wolf” so it should not contain any unnecessary settings or objects. You can download my policies here, ZIP-file, please note that this is provided “as is” with no warranties at all. Also please read this blog post about export and import of policies.