Are there any scheduled jobs or anything that would make Request (sc_request) records inactive?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We found that the state of Approval records related to Request records are being changed from requested to not_required and we thought that this may be due to the Request records being changed by the system to inactive for some reason. Upon further investigation, we have found that multiple records are affected all within a span less than a second.
There were no changes in the associated Request Item (sc_req_item) records that would've triggered the change on the Request records so I guess that rules out business rules here.
Is there any reason why the system would make multiple Request records inactive? Is it doing it through a Scheduled Job or Scheduled Flow? I have already checked both and couldn't find anything.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Definitely Active is getting false , but you need to check your configuration at what scenarios it is happening .
Any rollback of Flow/workflow ,your team performed..?
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
I have already checked through our configuration and could not find anything that’s why I was looking at the possibility that this may be OOTB.
Also, I would like to add that when the Request record is updated after it has become inactive, it changes back to active.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
It sounds like you have been focusing on record changes to identify what happened. Assuming you have access or can work with someone that does you should be able to trace what caused the updates.
If you have auditing turned on it should record every change made, the user (likely system given your description), and the time. What you really want is the exact time the change occurred.
If you have the exact timing of the change then you can review the system logs around that time and see if there are any log messages that may help identify what was done and potentially why. Next you need to check flow and process executions around that time and see if you can identify which one made the change. Once you know the process or flow you can identify what the trigger was and begin figuring out how to prevent it from happening again in the future if it was in fact buggy or undesirable behaviour.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @John Gilmore
Actually I did go through our logs, process executions and event queue, and I couldn't find anything that I could attribute the issue to.
I also checked my PDI and I have observed the same pattern - the Request record becoming inactive despite no changes on the Request Item record that would've triggered it being recorded. Left is the update history on the Request Item and the right is on the Request record.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Found a completely unrelated, misconfigured custom action that updates the state of sc_request records to closed_complete[4].