The CreatorCon Call for Content is officially open! Get started here.

How do you configure an Inactivity Monitor to only trigger inactivity events for a predefined duration?

Patrick Mutchl1
Tera Contributor

I am currently working on a requirement to have an inactivity monitor on the Problem table.  The ask is for the inactivity monitor to trigger at 5, 10, and 15 days.  The Problem will be escalated at 30 days, but they don't want notifications sent after 15 days.  I setup the inactivity monitor to trigger every 5 days, but I cannot get the conditions to work correctly so that it will stop sending notifications after 15 days.

Essentially, I was thinking that I could add a condition that looked at the 'sys_updated_on' field.  If it's within the 15 days window, fire off the notification.  If it's been longer than 15 days, however, don't trigger the inactivity event which triggers the notification.  It shouldn't send notifications at the 20 and 25 days marks.  Any thoughts on my this can be accomplished?

1 ACCEPTED SOLUTION

Hey Patrick,

You are correct and i had to re-read your original problem. I think i had an error in my thought process.

Your issue originates on how these inactivity monitors work. Essentially they fire an event periodically for as long as there was no update to the specified records. What you want to archive is to interrupt that periodic event generation. This, however, does not seem to be possible in a simplistic way.

The much simpler - yet unintuitive way - is to actually use an SLA for that. You can send notifications based on SLA events (described here). For that SLA set the status to be matched to anything but hold or close. Then add a reset condition which check for sys_updated_on changes. You can then freely set your duration for the SLA and use the oob SLA workflow to generate notifications at certain stages (or create your own workflow).

When using your own workflow you could even integrate the escalation into it as well.

In short: Inactivity monitors won't work for this, but a well defined - and more complex - SLA definition will.

Regards

Fabian

View solution in original post

3 REPLIES 3

Fabian Kunzke
Kilo Sage
Kilo Sage

Hey Patrick,

The most transparent way of doing this is to setup multiple inactivity monitors. The first one to be triggered after 5 days, the next one after 10 and so on. This also solves you "problem" of not sending one at the 20 and 25 day mark. Make sure to properly set up the reset conditions as stated in this docs link.

When you set this up i'd highly recommend to look into additional conditions as well:
- Should this run for all problems or just critical ones?
- What does this mean for problems which have a workaround?
- What does this mean for problems classified as a known error?
Essentially i would shy away from always triggering this.

The downside of this is ofc. that you will have multiple inactivity monitors running. The alternative to these activity monitors is scripting a scheduled job checking the inactivity time and then triggering a notification. However, i personally prefer using oob functionality such as the oob inactivity monitors.

Hope this helps.

Regards,
Fabian

Fabian,

Thanks for the quick reply.  If I setup multiple monitors, won't they start overlapping?  For instance, say I setup two monitors: 5-day and 10-day.  Wouldn't they trigger a 'problem.inactivity' event twice on day 10, one for event monitor?

Hey Patrick,

You are correct and i had to re-read your original problem. I think i had an error in my thought process.

Your issue originates on how these inactivity monitors work. Essentially they fire an event periodically for as long as there was no update to the specified records. What you want to archive is to interrupt that periodic event generation. This, however, does not seem to be possible in a simplistic way.

The much simpler - yet unintuitive way - is to actually use an SLA for that. You can send notifications based on SLA events (described here). For that SLA set the status to be matched to anything but hold or close. Then add a reset condition which check for sys_updated_on changes. You can then freely set your duration for the SLA and use the oob SLA workflow to generate notifications at certain stages (or create your own workflow).

When using your own workflow you could even integrate the escalation into it as well.

In short: Inactivity monitors won't work for this, but a well defined - and more complex - SLA definition will.

Regards

Fabian