- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 02:42 AM
I've a BR defined on the incident table. It's a "after" BR and "insert" is true, "update" is false. There are no filter conditions defined on it, so expectation is that it will run on every insert.
I noticed that upon creation of a certain incident in the past, the code that's written in the BR did not execute. So is there a way to track if the said BR had actually been run? I can't use "Debug Business Rule" because this is not real time tracking - rather whether the BR executed in a past time or not.
I've the timestamp at which the incident was created. So if there's a place where BRs are also tracked, I can filter close to that timestamp. (pretty similar to the sysevent table where all events that were fired are logged). So hoping there is something for BRs as well.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 04:15 AM
Hi @Nisar3,
Sadly, there isn't any built-in feature that provides a direct way to view retrospective execution history of a Business Rule. (Or not that I'm aware of. The stack trace is not available via system logs, transaction logs or even node logs).
The only thing you could possibly try is viewing the Audit History against the said record(s) and check the source column to see if a Business Rule made the change - however, based on the fact you don't see the change - this seems as if it won't really help - sorry.
As @Uncle Rob has mentioned and I'm sure other will, you have a couple of options for record moving forward (but sadly not retrospectively) by either using a simple gs.info() statement or leveraging the Script Debugger. (Check the Script Tracer which is a pretty cool tool to leverage for stack tracing).
To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.
Thanks, Robbie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 02:53 AM
You could use breakpoints in your script:
https://www.servicenow.com/docs/bundle/xanadu-api-reference/page/script/debugging/task/set-remove-lo...
Or you could do it the old fashioned way and just put a gs.info message in the script.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 03:20 AM
Thank you. But like I said, the transaction happened in the past and making changes in the script now will only work for future instances whereas I'm trying to figure out if something happened in the past. So this solution won't work in my case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 04:15 AM
Hi @Nisar3,
Sadly, there isn't any built-in feature that provides a direct way to view retrospective execution history of a Business Rule. (Or not that I'm aware of. The stack trace is not available via system logs, transaction logs or even node logs).
The only thing you could possibly try is viewing the Audit History against the said record(s) and check the source column to see if a Business Rule made the change - however, based on the fact you don't see the change - this seems as if it won't really help - sorry.
As @Uncle Rob has mentioned and I'm sure other will, you have a couple of options for record moving forward (but sadly not retrospectively) by either using a simple gs.info() statement or leveraging the Script Debugger. (Check the Script Tracer which is a pretty cool tool to leverage for stack tracing).
To help others (or for me to help you more directly), please mark this response correct by clicking on Accept as Solution and/or Kudos.
Thanks, Robbie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2024 04:26 AM
That's a bummer. Will await to see if anyone else has different views, if not will accept it.