- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 06:20 AM
Hello Community,
Need your help to trace an update made by system on five incidents. Its not listed in the history section nor in the activity list of these incidents. Any pointers would be helpful to find what exactly the system has updated. Attaching few screenshots.
All fields are selected on the activity log filter but still it doesn't show the above mentioned update.
Even the History list view of the incident doesn't list it.
The Calendar view of the history does show this entry of updated by system but doesn't mention the details of what exactly is updated.
Solved! Go to Solution.
- Labels:
-
Incident Management
- 7,431 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2019 04:16 AM
Hello Community,
After researching a bit on community and following some clues from Mark and my colleagues, I found that its due to the 'Inactivity Monitor' which is enabled in my instance for Open P-1 incidents and runs every two hours.
I found that the last updated time is being changed every two hour and the updated by is 'system' for the same set of incidents which are all P1 incidents and not closed ones.
To trace it and confirm this, I looked for the Events under System logs with name 'incident.inactivity' and found there are 5 events with exactly same time stamp as the 'Updated' on the incidents.
To further investigate, I checked details of the events and the sysID mentioned in the instance of each event does match with the sysID of the incidents, which confirms that this is the cause of those updates. One of the incident with same sysID is shown below:
Event Details:
Incident sysID highlighted in the URL:
Although this cleared that who's the culprit, but the question still remains, what exactly it updated? And In the first place, why a monitoring feature would ever update the very same record which it should have JUST monitored?
In fact if you read the Docs it states the reason for this feature is to avoid tasks falling wayside. But if this feature is active and you are using reports to track/chase the tasks/incidents not being updated since x amount of time, by using 'updated' time stamp, then it will mess up that report. So do check the validity of any such report if you see frequent or regular updated by 'system' on tasks/incidents/changes.
The Docs about Inactivity Monitor doesn't state anything about how it function and why it updates the task/incident?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 06:23 AM
Hi there,
Some possibilities would be a scheduled job (don't guess so seeing the timestamp, a workflow with a timer (and therefore running as system) or a flow designer for example.
If my answer helped you in any way, please then mark it as helpful.
Kind regards,
Mark
---
LinkedIn
Community article list
Kind regards,
Mark Roethof
Independent ServiceNow Consultant
10x ServiceNow MVP
---
~444 Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 07:21 AM
I would agree with Mark. You need to look at the details of the update (what changed) in order to figure out what job is running.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2019 01:04 AM
Well tracking the change has two parts:
1) What has changed i.e. which field?
2) The trigger or source of that change.
Unfortunately I could not find either. I have seen the scheduled jobs and nothing matches the time stamp of last updated on. Further all jobs are Data collection jobs for Performance Analytics and ML, so I don't expect them to be messing around with any data except collecting it.
Meanwhile there was another update on the same incidents today at 10-16-2019 08:15:08 GMT(London), So I also think its something scheduled that is doing this. I will the workflows as well.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2019 02:28 AM
Information exempted from auditing
Some updates are not audited despite enabling auditing on a table. This is why you may see 132 updates in a record's history, but only seven audited ones.
- Any updates made by an upgrade.
- Any updates made through import sets.
- Any records in parent or child tables.
- Any field with the no_audit dictionary attribute.
- Any system tables not listed in the glide.ui.audit_deleted_tables property list.
- Any field that begins with the sys_ prefix (system fields) except the sys_class_name and sys_domain_id columns.
- Any time an inactivity monitor touches a record (this prevents you seeing possibly hundreds of updates listed against an incident, with the noise drowning out the useful data).