Business Rule Against User Table Inconsistent

Steven Parker
Giga Sage

yesterday - last edited yesterday

This is for our PROD instance.

 

We have an After business rule that runs after a user is inserted into the sys_user table.  Here is the "When to Run"

StevenParker_0-1767716279521.png

 

In the "Advanced" tab we have a simple script that kicks off a catalog item.  This script was created in February 2025 and has been running perfectly ever since.

(function executeRule(current, previous /*null when async*/) {

//Get today's date
var now = new GlideDateTime();// Get Today

//Setting up the cart
var cartId = GlideGuid.generate(null);
var cart = new SPCart(cartId);

//Setup Access Review Details field on request form
comments = "Opened Automatically by ServiceNow when a new user record was identified.";

//Add Access Review Item to Cart
var item = cart.addItem('ebce30e81b60de901a400ed5604bcb48'); //New IT Team Member Training

//Set Variables for Access Review Cat Item
cart.setVariable(item, 'requester', current.manager);//Team Member's Manager
cart.setVariable(item, 'requested_for', current.sys_id);
cart.setVariable(item, 'hire_date', now);
cart.setVariable(item, 'manager', current.manager);
cart.setVariable(item, 'comments', comments);

//Set Cart Requested For
cart.setRequestedFor('6816f79cc0a8016401c5a33be04be441');//System Admin sys_id		

//Submit Catalog item		
var rc = cart.placeOrder();

})(current, previous);

  

Yesterday, we noticed we had 4 new IT employees hired, but only one of them had the "New IT Team Member Training" item open.  Reviewing the LDAP import sets, everything looks normal with the users all having a department, email, etc...so each person should've went through that script and kicked off a "New IT Team Member Training" item.

 

Here is the one RITM that was opened by the System Administrator:

StevenParker_1-1767716517048.png

 

Considering we don't add new users everyday, this is hard to test.

 

In DEV, we are on Yokohama Patch 10 Hot Fix 1, but PROD isn't updated yet (it's still on Patch 8 and updates next week).  All plugins in PROD are updated (DEV is not as it's very time consuming).  Security Incident Response is a plugin we use and starts to come to mind when issues like this arise (being scoped and all and the system admin having sn_si.admin role OR maybe an ACL change or something as part of the update).

 

But what's strange is, why did it create 1 of the request successfully, but not the other 3?  Testing in DEV by creating a new user (we don't LDAP import users into DEV), the script works fine and creates whatever it needs to.

 

I am a little bit lost as to what's going on here...especially since it created one successfully, but not the other 3.  The user records and LDAP import sets show that the user had all the needed criteria to run the Business Rule for each person.  The created and updated dates also match for each of the 4 users on the user table so no updates have been made to the records (meaning Department was present when created).

 

 


Please mark this response as correct and/or helpful if it assisted you with your question.
Steven
0 Helpfuls
  • 161 Views
1 REPLY 1

Brad Bowman
Kilo Patron

yesterday

Do you see anything in the system logs around the time the 4 user records were created?  Do you have auditing turned on (for the condition fields) on the user table so that you can confirm with certainty that the records were created with field values that matched all of the conditions?  Either the Business Rule is not triggering in these cases, or it is but the script is failing to produce the Service Request.  Without logs in the script, it may be hard to determine which is the case.  Do you ever create user records that are inactive and/or somehow created on a different date?  If not, I would remove the unnecessary condition(s) from the Business Rule.

0 Helpfuls