- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2020 12:34 AM
Dear all,
As the title mentioned, I am trying to create a reminder for Problem ticket which is not updated since last 7 days. Currently my way of achieving it is :
1. Create an event
2. Scheduled a script that run thru all Problem ticket and check which Problem is not updated since last 7 days and fired the event
3. Event fired will trigger an email notification.
Is there a better way to achieve the same? I am exploring different options.
Thank you in advance.
with Regards,
Jake
Solved! Go to Solution.
- Labels:
-
Problem Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2020 12:45 AM
Hello Jake,
Scheduled jobs with events is the right approach. You are on right track.
Ensure you create the event and notification on problem table.
Kindly mark the comment as a correct answer and helpful if it answers your question.
Regards,
Asif
2020 ServiceNow Community MVP

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2020 12:45 AM
Hello Jake,
Scheduled jobs with events is the right approach. You are on right track.
Ensure you create the event and notification on problem table.
Kindly mark the comment as a correct answer and helpful if it answers your question.
Regards,
Asif
2020 ServiceNow Community MVP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2020 05:30 AM
Hi ,
You can do through the "script actions" also , but you need event to trigger script actions.
Please mark it as helpful if it helps.
Thanks,
Sumanth
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2020 08:45 AM
Few thoughts:
- They way you said it, "Run through all Problem ticket and check which problem ticket is not updated in the last 7 days" makes me think this job would possibly be looping through many unnecessary records. Perhaps you meant "Query for all active problems that were updated more than 7 days ago"
- Also I wonder do you want to send a new notification each day, every day, forever, or just one notification after the 7-day threshold? Maybe the date filter should be "...problems that were updated more than 7 days ago and less than 8 days ago"
- How often would such a job run? Would it run once a day? If so, are you looking for problems that had not been updated before 7 days x 24 hours ago or ones were updated before the start of the day 7 days ago. In other words, if the job runs at 9:11am Feb 11, do you want to notify all users with problems updated before 9:11am Feb 4 or 0:00am Feb 4?
- I don't understand why you are firing an event in step #1 and then using a scheduled job to loop through all problems with events in step #2. Why not have the job fire the event? What is the purpose of the event fired in step #1. I think this is what Asif was getting at in his comment. Events and jobs are a correct approach, its just that the order of operations you listed needs a little tweaking.
So... one example of a pattern that would work (in pseudo code) is:
- Scheduled job runs at 8:14 am every morning (good idea not to schedule jobs to start at the top of the hour or when users start to come online)
- Job queries for all active problems that were updated before 8am 7-days ago and after 8am 8-days ago (we don't need to loop over whole table and we don't want to continue to notify forever)
- Loop over results, creating events for each problem (gs.eventQueue(...))
- These events then trigger a specific email notification that is on the problem table designed to notify users that their problem has not been updated in 7 days
Another way to do this would be with an Inactivity Monitor. This is an old feature in the platform so many are not aware of it, but it does exactly what you are trying to do. I think I prefer the idea of using a single custom scripted scheduled job instead because it would be less system overhead in general but Inactivity Monitors would certainly work and would require a little less configuration and coding.
If the task (problem in your case) remains inactive, the monitor repeats at regular intervals. User updates to the task record restart the monitor. If reset conditions you defined for it have not been met, the monitor does not restart when you update the task record. Inactivity monitors only apply to records on tables that extend the Task table, or the Task table itself.
When an inactivity monitor triggers, it generates an event in the form <tablename>.inactivity (for example, incident.inactivity). Define an email notification or script action to drive further action for the inactivity monitor.
In the end, there's probably a million ways to do what you are trying to do with ServiceNow. For example, if you have a workflow or flow designer that is already attached to your problem table, perhaps you can put a loop in that flow with a 7-day timer that checks to see if there has been an update.
Good luck!