Inbound Email Action to Update User Record Sometimes Fails

[jmiskey]

We have an Inbound Email Action where we forward emails received in a department mailbox to ServiceNow to update a Transfer Date field found on the User Record.  The Inbound Email Action script parses the Employee Number and Transfer Date fields from the email, and is supposed to update the User Record.

I have verified through logging that it is pulling off the correct values for Employee Number and Transfer Date.  So there do not appear to be any issues there.

Here is the script:

//get values from email body
var ebody = email.body_text;

//find employee number
var ee_num = '';
var match = ebody.match(/Employee Number:\s*(\d{6,7})/);
if (match) {
    ee_num = match[1];
}

//get transfer date string
var temp2 = ebody;
var b = temp2.indexOf("Effective Date of Change:");
temp2 = temp2.substr(b + 25, b + 50);
temp2 = temp2.trim();
temp2 = temp2.substr(0, 10);

//convert string to date
var x = temp2.split(" ");  //date looks like "2023 10 18"
var yr = x[0];
var mo = x[1];
var dy = x[2];
var dte = yr + '-' + mo + '-' + dy;
var xfer_date = new GlideDate();
xfer_date.setValue(dte);
gs.log("ADD TRANSFER DATE: xfer_date = " + xfer_date);

//only update record if ee_num is not blank
if(ee_num!=''){
	//update Transfer Date on user record
	var usr = new GlideRecord('sys_user');
	usr.addQuery('employee_number', ee_num);
	usr.addQuery('active','true');
	usr.query();
	gs.log("ADD TRANSFER DATE: record count = " + usr.getRowCount());

	while (usr.next()) {
		gs.log("ADD TRANSFER DATE FOR: " + usr.employee_number);
		usr.u_transfer_date = xfer_date;
		usr.update();
		gs.log("ADD TRANSFER DATE RECORD UPDATED");
	}
}else{
	gs.log("ADD TRANSFER DATE: Cancelled as no Employee Number idenitified");
}

It sometimes works, but not all the time.  When it fails, the error message I get is:

"Did not create or update sys_user using current".

I am not sure why it works for some emails and not others.  I thought maybe at first it was a permissions thing, but I compared user records that worked versus records that don't, and those users have the exact same roles.  So that is not it.

Any idea why I get these errors on some people and not others? 

Any idea on how I might update my script to prevent this from happening?

[Ankur Bawiskar]

@jmiskey 

unless you debug you won't know where it failed.

You should be able to replicate it in DEV

If my response helped please mark it correct and close the thread so that it benefits future readers.

[jmiskey]

As I said in my previous response, I am unable to replicate this in DEV - it worked in DEV.  And it worked in UAT, which was a clone from just two days ago. 

It seems totally random on why it works only for certain records in PRD, but works for all records in other environments.

[David Dietrich1]

Here are some things I would do...

First, check for business rules on sys_user where script contains current.setAbortAction(true).

Second, add a log statement to capture situations where the user is not found:

if (!usr.hasNext()) gs.error("ADD TRANSFER DATE: unable to find user by query " + usr.getEncodedQuery());

Third,  wrap user.update() in a try...catch block, like this:

try { usr.update(); gs.log("ADD TRANSFER DATE RECORD UPDATED"); }
catch (expn) { gs.error('ADD TRANSFER DATE: exception "' + expn.message + '" for user ' + usr.sys_id); }

[jmiskey]

Guys, I have to really apologize on this.  I made a mistake.  We have two Inbound Email Actions, as the emails may come from two different places.  I had identified the wrong one - it was not the Inbound Action/script I identified in my original post, but rather the excellent one Ankur provided to me recently in this thread here: https://www.servicenow.com/community/developer-forum/parsing-text-for-inbound-email-action/m-p/32478...

The issue was that some have an extra word in the Subject Line, causing the Regex line to fail.  I was able to modify it to make it work out.

I am truly sorry for my error and thank you all for the assistance you provided.

[Ankur Bawiskar]

@jmiskey 

Glad to help and no worries.

If my response helped please mark it correct and close the thread so that it benefits future readers.