Review Activity Reminder

The post below shows how to use Orchestrator as a tool to “remind” users that they have a review activity to complete – however they have failed to do so within a certain amount of time. Every organisation has that one user that they have to wait on for ages to get an approval. Why not get them into trouble when they don't approve something within a reasonable time frame.

I created a Runbook to check all the change activities with a status of in progress and select any review activities within which have a status of pending. Comparing that to a time limit – if the activity has breached that limit I generate an incident from a template I have created. The second time the Runbook is triggered – if an incident already exists I escalate it. You can then attach an SLA to this – make your tardy users become responsible for not approving an activity within the timeframe your business specifies.

Of course this is only a basic framework and would require more customization / testing if you use it for your environment.

The basic Runbook is below: -

It starts off with a monitor date/time activity – I have this running every 5 minutes in my environment for testing purposes. You could get creative and attach a schedule to this so it only runs during business hours etc.

Next step is to get all the change requests which have a status of In Progress – if you were to adapt this to other records you would need to duplicate the Runbook as you cant select a class dynamically.

I then use a Get Relationship activity to return all the review activities associated with the In Progress change requests.

Once I have the related objects I get the review activities which are set to In Progress – this prevents me from alerting on activities which are completed or in a pending state.

Time for some PowerShell – the script in the next activity is rough – I have created a variable to hold my breach time (10 minutes). There is also some messing around with the times from Service Manager – this is due to my environment and needs to be tested thoroughly. Also I use the created date from the RA – this is not going to be correct when a change has multiple review activities and needs to be fixed – I’ll do a later post to fix this. I publish the $result variable and test it in the links ahead.

Now I check for an incident which contains the review activity and my custom title in the incident title. Later on when I create the incident from a template you will see I have populated the title value with a specific string so I can search for it here.

If this is the first time the breach has been activated (number of incidents returned = 0) – the Runbook now splits and creates a new Incident using a template I have created in Service Manager. I populate fields as below.

• Impact = Medium
• Urgency = Medium
• Title = {ID from “Get RA”} – Review Activity Breach
• Description = {ID from “Get RA”} has breached the approval time of 30 minutes.
• ID = IR{0}     ----------------   Note: putting {0} will force the Incident to take the next available ID
• Status = Active
• Source = System   ---------   Note: Source is a mandatory field inside the Incident template.

Because I’m nice I then add the Review Activity to the Incident as a related item using a Get Relationship activity – so the person resolving the issue has an easy way to find the activity.

So what exactly happens? I create a new Change Request which contains a review activity – start my Runbook and let it sit for ten minutes until the Runbook has run a couple of times and the review time is breached. Here is my review activity I’m waiting on.

The first time the Runbook runs it detects that the review time has not been breached and just finishes as below.

The seconds time it ran it was still not breached – I also created another change request to test what happens when multiple review activities are In Progress and have different breach statuses.

Now I have one activity with a status of breach so I can create an incident from it – as expected it appears in my Service Manager console with my custom title and the work item attached.

Expected behaviour on the next run is that it will detect an Incident is already open for this review activity. So I branch off and use an Update Object activity to set the escalated flag to true.

This time when it runs – my original review activity is seen as having an incident raised – so it is escalated. Meanwhile the other review activity has also been breached so it creates its own incident.

Finally both incidents are escalated.

In order to stop the Update Object activity from running every time I have added some logic into the link to check the escalation status before updating.

The number of objects returned will equal one (to check that an incident has been raised for a review activity). I then exclude any results which have the escalated flag set to true – so that the activity doesn't keep re-running.

Finally when both incidents are escalated the Runbook will run however will stop at the Get Incident step as none of the filters will be fulfilled.

In a future post I will look at tidying up the detection – as activity created date is not quite correct, and also generating an overall rating for each user who fails to approve activities in time!

Comments

• Anonymous
  December 10, 2014
  In the last post I showed how to “move along” users who are slacking at doing their approvals. This post