Inactivity Monitors Not Behaving as Expected

[Andrew Bettcher]

I had an inactivity monitor working after logging a case with HI. They didn't explain what the issue was except to say that I didn't have a notification set up to do anything. I thought the event would fire regardless but sure enough, adding a notification did the job.

That was about 3 weeks ago. I have recently deployed this as solution but it isn't working again. 

I can see the scheduled job but it doesn't do anything when it completes. No event. 

I have a notification set up. 

I read here that Parm1 contains the sys_id of the incident record that triggered the event. In all cases I can find in my instances and in my developer instance the inactivity monitor parm1 contains the sys_id of the inactivity monitor. This indicates to me that something is going wrong somewhere. Parm2 is empty.

My inactivity monitor looks like this:

Nothing complicated. I've logged another ticket with HI but thought I'd take a punt on the forums.

I actually want to test a notification script that will only send inactivity notifications after consulting a schedule but I can't test it if the event doesn't fire at all (under any circumstances!!)

I have tried setting an even more basic inactivity monitor with just "Active = True" but still nothing. 

Tearing my hair out.

[Kieran Anson · Accepted solution]

Hi,

Activity monitors create events <table_name>.inactivity. param1 is the ID of the inactivity, the "instance" will be the table record value. If you go to the sys_trigger table, you should see records with the name activity.monitor timer <record display value> like below. This is what is actually doing the triggering.

If HI haven't helped you with these checks I'd start by,

• Checking the event log tables contains incident.inactivity events
• Check the sys_trigger table to see if any schedule records exist.

[Andrew Bettcher]

That is incredibly useful thank you.

However, over the weekend my test email account received a number of inactivity monitor alerts (from our PROD instance). When I looked at the tickets the time frames don't match up.

I had a "New" ticket come is at 1544 on Saturday. The agent picked it up and moved it into the next stage (i.e. NOT "New"). It appears that once he had done this the inactivity began timing another 30 minute period because I receive the notification email 30 minutes later. 

The inactivity monitor is set to time incidents that are "New" and assigned to "Service Desk" and so I would have expected the monitor to ignore this ticket once the status had changed.

I can't offer my customers a reliable solution and, because these alerts will be going to a 3rd party if our own Service Desk doesn't respond then I need to make sure that they are correct. I'm going to implement SLAs that time and notify mainly because I know what I'm doing and I know that this will work.

Then I will look at deploying my own timer once I've got a working solution in place.

Thank you for your excellent help. 

[Daniel Oderbolz]

I am surprised to see that the inactivity monitors do not use metrics (that would be a way to create Schedule Aware Metrics)

It seems that it is quite hard to be able to report on inactivity (taking into account a Schedule).