Inbound Actions - Getting the email sysid

[jwawa1]

We occasionally have users Reply to catalog request notifications, which we currently have no process in place to handle. We've considered creating a new Inbound Action to update the activity log of the request, but since our ITIL users don't work from catalog requests (they work from catalog tasks), the replies would go unnoticed. Instead, we'd like to fire an email off to notify our service desk manager when one of these unprocessed emails is received by service-now. In that notification, we'd like to include as much information from the original email as possible, as well as the number for the related record that was replied to.

The main problem I can't figure out is how to get the sysid of the email record being processed in the inbound email action, so we can pass that to an event and send a notification. I'm open to other ideas on how to address this scenario (note, it's not only on sc_requests though. Same scenario could happen if a user replies to a change request notification, or a survey, or a closed incident, etc). But the question I'm hoping to get some insight into first is "How can you get the sysid of the current email, when inside an Inbound Action?". It doesn't appear to be as simple as "email.sys_id".

[dmartinc]

Dear jwawa,

One of the attributes of the "email" object that is available in Inbound Actions is the email's uid : email.uid . Sadly it is not documented (http://wiki.service-now.com/index.php?title=Inbound_Email_Actions) but you can see it is there if you print all the attributes of the email object: for (i in email) {gs.log(i);}

This uid corresponds to the "uid" column of the sys_email table. So all that's left is to do a GlideRecord query to the sys_email table with this uid as condition (maybe you also want to add the creation time +-5min as condition because the uid is not guaranteed to be unique; you can also add the subject, recipients, even the body as conditions in order to eliminate duplicates).

Another option is to make a Business Rule that detects that your email has not been processed; for this you can detect that after update, the "target" column of the sys_email record is empty. In the Business Rule you will have access to the sys_id of the sys_email record without having to resort to using the uid.

Cheers,
David

[jwawa1]

I wondered if UID might be usable, but I wasn't sure if it would be unique enough to be relied on. The 'time test' seems like a good solution to that concern though. But I also like the idea of the business rule. I'll have to mull it over and decide which way to go.

Thanks for the ideas, David.
-Joe

[jwawa1]

On the business rule idea, after a new message is inserted in the sys_email table, it takes a while for the Inbound Actions to finish processing it and updating the 'target' (instance) field. So if I create a business rule that needs to make decisions based on whether the 'target' is empty, I'll run into problems since it will often be empty only because the inbound action hasn't finished processing it yet. Any ideas on how to best account for that? I don't think I like having a business rule intentionally doing nothing for 5 minutes every time it runs, but is there any other option besides a 'wait' timer within the business rule? Maybe using gs.eventQueueScheduled to set an event for 5 minutes into the future, which then triggers a script action?

On the Inbound Action idea, instead of a +/- 5 minute condition, another option might be to get the newest match. Something like this, maybe...

//find newest match for an email with a matching UID
var em = new GlideRecord('sys_email');
em.query('uid', em.uid);
em.orderByDesc('sys_created_on');
em.query();
if(em.next()) {
  //we've found the newest matching email message for this uid
  //further processing here
}

Thanks again for any input,
-Joe

[dmartinc]

Hi Joe,

Yes, sure. While it is true that the target is null on creation, the "state" of the email will change to "Processed" after the Inbound Action takes care of it. So you could make the Business rule be "on after update" (but not after insert) and check that both the status is Processed and the target is empty.

In any case, I'm saying this without verifying the exact names/values of the fields; so what I advise you is that you send a test email, and then refresh the "Inbox" mailbox until you see it appear there. Show all the columns of the table so that you can see all the fields without changing the sys_email form layout.
Then, in another browser tab, do the same thing refreshing the "Received" mailbox until you see the mail appear there. You will then see all the differences of fields between a mail that just arrived and a mail that was just processed and you can use that in your Business Rule to distinguish exactly the mails you need from the others.

Cheers,
David