Need to track an update by 'system'

Gautam7
Tera Expert

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.

find_real_file.png

 

All fields are selected on the activity log filter but still it doesn't show the above mentioned update.

find_real_file.png

Even the History list view of the incident doesn't list it.

find_real_file.png

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.

find_real_file.png

1 ACCEPTED SOLUTION

Gautam7
Tera Expert

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.

find_real_file.png

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.

find_real_file.png

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.

find_real_file.png

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:

find_real_file.png

Incident sysID highlighted in the URL:

find_real_file.png

 

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.

find_real_file.png

 

The Docs about Inactivity Monitor doesn't state anything about how it function and why it updates the task/incident?

 

 

View solution in original post

5 REPLIES 5

Mark Roethof
Tera Patron
Tera Patron

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

LinkedIn

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.

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.

 

Sandeep Rajput
Tera Patron
Tera Patron

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.

Auditing excludes the following information:
  • 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).
In your case, it looks like the inactivity monitor has touched those records.