- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2022 02:01 PM
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?
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2022 01:39 AM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-04-2022 01:15 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-04-2022 01:36 PM
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?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2022 01:39 AM
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