What about days when no one feels responsible for assigning Incidents to Support Groups and/or Analysts? In such cases a workflow that reports unassigned Incidents would be helpful. If needed, the workflow could also assign these Incidents automatically to a Support Group or an Analyst. In this post I will show you how this can be done by using the SCSM Extensions V2.0 OIP in combination with the SCSM OIP from Microsoft.

This is how the workflow could look like. This is just an example and you could add much more Activities as needed. But this will be a good starting point for further development of the workflow.

Now let’s see what those Activities are for.

• Delete File

I use a temporary file to store information. Because this is the same file every time the workflow runs, it will be deleted first.

• Get unassigned Incidents (no Analyst and no Support Group)

Now we get all Incidents that are not assigned to an Analyst nor to a Support Group. This Activity comes from the SCSM Extensions V2.0 OIP.

• Compare Values

To make sure that action only happens when there are completely unassigned Incidents (no Analyst and no Support Group), this Activity checks if the previous Activity returned results or not. Published Data (Incident Title) can be used to check that.

It’s now important to configure the next Link correctly. To workflow should only proceed when the Published Data (Incident Title) is not empty.

• Get Object

This Activity comes from the Microsoft SCSM OIP. I need it to get the Object GUID from all found Incidents. This GUID is needed to update the objects with the next Activity. To get the GUID I set a filter to the ID and use Published Data from the “Get all unassigned Incidents …” object. This means, that it will get the GUID for every Incident that was found in our workflow.

• Update Object

I will now use the second Activity from the Microsoft SCSM OIP to update the Support Group attribute to the desired Tier. To specify the GUID I use Published Data from the “Get Object” Activity. Then, I choose the “Support Group” attribute and select the Tier from the list.

• Append Line

Because I want to inform someone about the auto-assignment of those incidents, I will write some information to a file. The content of this file will later be used as the body for a notification mail. I just use the ID and the Title of the Incidents for this example.

• Junction

The Junction Activity is needed to make sure that only a single Mail is sent to the recipient. Without a Junction, the recipient will get one Mail for every Incident that was assigned before. No special configuration is needed for this Activity.

• Read Line

With the next activity we are going to read back the information that was written to the temporary file before. It’s important to flatten the results with line breaks.

• Send Mail

The last step is creating a notification mail with the information already stored in the text file. I again use Published Data to get the file content to the mail body.

Now when testing the workflow, all unassigned Incidents will automatically become assigned. The notification mail will inform the related persons about the task.

Now check the settings on the Incident. Believe it or not, the Support Group attribute was empty before.

To run this workflow periodically, you can add a “Monitor Date/Time” Activity at the beginning.

I will create some more workflows on how to use the SCSM Extensions V2.0 OIP to automate tasks. Stay tuned …

regards
Marcel