Tips & Tricks: How to understand sys_created_on and before insert business rules

Tips & Tricks: Understanding sys_created_on and before insert business rules.

 

Our first blog post of the series helps users understand ‘sys_created_on’ and ‘before insert’ business rules, and it was created in with our incredible ServiceNow consultant Niko Sääski. A big thanks to Niko for his wisdom! In the end we’ve inserted visual guide to help you even further. Let’s get into it!

 

Problem: Slow “before insert” type business rule and understanding how ServiceNow populates “sys_created_on” field


Challenge: In this case the issue was verifying our hunch that a slow business rule was causing the problems. Checking the sys_created_on and sys_mod_count fields of the records was throwing us off the right path.  Our Workflow finished, and it appeared from the timestamps that the integration records had been created before the Workflow finished. The problem arose when the system failed to process records created during an integration. This caused errors to the API consumer in turn.


Solution: We could not touch the “before insert” business rule, because it was encrypting sensitive data so that agents using the instance could not view it. Modifying our integration Workflow addressed the issue.


Technical side: The value for “sys_created_on” populates before the “before insert” business rule runs. If the business rule runs for several minutes, the timestamp will indicate the moment when the record still couldn’t be found from the system.
Steps with pictures show how to verify this behaviour. Tested in Tokyo patch 10 hotfix 2b.

 

Benefits: While it is not ideal to have long running business rules, sometimes they cannot be avoided. This is why it’s good to understand the workings of “sys_” fields.

 

Technologies used: ServiceNow

 

Visual guide

 

Set up a before insert business rule with a script in order for it to run for 5 minutes

Set up a before insert business rule with a script in order for it to run for 5 minutes
Images 1 & 2: Set up a before insert business rule with a script in order for it to run for 5 minutes

 

Image of In background script set up a “sys_trigger” which creates a new incident record
Image 3: In background script set up a “sys_trigger” which creates a new incident record

 


Image 4: “sys_trigger” record is lined up and gets to processing.

Image 5: “sys_trigger” record is lined up and gets to processing.
Images 4 & 5 depict the system lining up and processing the “sys_trigger” record..

 

 

Image 6: In the module “Active Transactions (All Nodes)” can verify that business rules are being ran against our test incident

 

Image 7: While the business rules run, we cannot find the incident.

 

Image 8: After the processing completes, the incident appears on the list with the timestamps indicating what happened. The system forms the “sys_created_on” timestamp before the “before insert” business rules complete We can verify that from the timestamps in the description.

 

Thank you for reading and we hope this was helpful content.

For more content like this please go read our other blogs from this link: https://appmore.com/resources-2/

 

 

DE