Attempting to identify a users email using alias email address

[EricG]

I've seen several posts like the one below about how ServiceNow parses the from address and matches it to the user table.

Example Post

I'm unable to identify what script, business rule or inboud action is being used to inital parse the emails' from information.

My goal is to modify this and add an additional step to also look in the Notification Devices table for the non matched email to bring over the correct sn user id.

Currently, we are getting our User Information from HR, which on some records, may not have the current/correct email address.

Example;  Mary Joe is an HR person for our Company B.   She is using that companies credentials instead of using her employment company (Company A).

Does anyone have examples of doing this or can you lead me to where the OOB rule is.

Thanks.

[EricG · Accepted solution]

Thank you all for your comments and suggestions.

I was able to finally get this working.  So if anyone else needs to do this, here are the steps i was finally able to put together form everyone's suggestions.

1. Created a Custom "Alias" table, with columns for User (reference) and alias email (string).
**Found that the OOB "Notification Devices" table was replacing the alias email entry with the corresponding user table email address, even if I added another "Method" selection.

2. Created a before insert and update BR to update the email record's User_ID and user fields.

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

	// Add your code here
	var currEmail = current.user;
	var fndAlias = new GlideRecord("Enter Custom Table Name here");
	fndAlias.addQuery('u_alias_email',currEmail);
	fndAlias.query();

	while(fndAlias.next()){
                //This updates the email with the desired results.
		current.user_id = fndAlias.u_snow_user;
		current.user = fndAlias.u_snow_user;
		current.update();
	}
	//THis is key to reprocess the email with alias.  If not included email will not process.
	gs.eventQueue ("email.read", current, current.sys_id, current.user_id); 
})(current, previous);

You might wonder why I'm doing a Before on Insert and Update.  I first tried using only Insert as true, but I couldn't get the email to update.  Then chose Update is true, and got the email to update but reprocessing didn't always add the user name to the corresponding ticket created.  So finally, did the combo of both and Viola!  Success.

This was really import for validating existing and new inbound Flow's in my lower environments when i pull sample emails collected from production.  Only having one or the other set as true, didn't allow for testing having a user email sub prod directly.  Also helpful hint.  I copied by "Final" catch all inbound flow to include my sub environment email address, which isn't included in my production ones.