Cannot read the "email.origemail" from a Business Rule script

[Mihail3]

From within the script of a Business Rule on the sys_email table, I try to access to the "email" object in order to read the "origemail" attribute. (this attribute is described here)

If i try to use the following in my Business Rule script:

gs.log("Sender is:" + email.origemail);

then it fails with error org.mozilla.javascript.EcmaError: "email" is not defined.

If I try to use the following in my Business Rule script:

gs.log("Sender is:" + current.origemail);

then it logs "Sender is:undefined"

Can anyone suggest me what Glide* objects I would use to access the "email" object from the Business Rule script and read the value of "origemail" ?

Many thanks,

Mihail

[Mike Patel]

Based on Doc looks like it's only available in inbound action script. 

https://docs.servicenow.com/bundle/london-servicenow-platform/page/administer/notification/reference...

[Jim Coyne]

We might be able to suggest something different if you let us know what you are trying to do in the Business Rule.

[Mihail3]

Thank you Jim for your reply.

I managed to achieve what I needed by splitting my logic into a Business Rule and an Inbound Email Action.

For those who come accross this post, this is what I tried to achieve:

My company transitions from email-based tickets to Service Now. Previously, people were used (and still have this habit) to send emails to a shared Exchange mailbox instead of opening the Self-Service page in Service Now. We've set a forwarding and now the emails arrive in Service Now.

This is not a new use-case for most companies, except that the end-users most of the times send brand new emails (without any reference in the subjsect or in the body to existing ticket) asking for status updates of existing incidents and by default Service Now thinks that these emails are new incidents (where in fact they are not). If we leave the default behaviour of Service Now in place, then we end up having an invasion of new tickets just to discover they are just follow-ups on existing ones.

At this point there are three approaches that I'm aware of when people set-up a new Service Now instance for a company:

1. Find a way (UI actions, scripts, etc.) to merge the excess incidents (created from follow-up emails, as described above) into the main tickets where the ITIL workers do their work.

2. Do a cut-over switch from email-based ticketing to Service Now where the previously used mailbox suddenly does not accept any emails and the end-users are forced to use the Self Service only.

3. Find a way (UI, actions, scripts, etc.) to incercept all those emails that Service Now could not automatically match against existing tickets and give the ITIL workers the possibility to manually assign those emails to existing tickets or new ones.

My company decided to go for the 3rd approach, because perhaps they were not aware of other better approaches.

If there are any better approaches, please post replies.

To implement the 3rd approach, I did the following:

• Forced the instance to treat all incoming emails first as replies, by setting a rare string combination as a reply prefix, instead of the default ones "RE:", "AW:", etc. At the same time I set a transport rule in our Exchange server to prepend the same rare string combination to all email subjects that were heading towards the email address of our Service Now instance;
• I added a few extra fields on the sys_email table: One field that indicates the manual action to take (Create New or Update Existing), one field that chooses the ticket type and a another reference field that would lookup the ticket depending on the ticket type selected in the previous field.
• I modified the Inbound Actions to add extra conditions based on the above fields and as result, all emails which could not be matched automatically by Service Now to existing tickets will remain in a queue called "Unallocated Emails";
• I created a Business Rule that is triggered whenever an email is updated and modifies the email's subject by prepending the number of the ticket which was selected manually by the ITIL worker.
• I created a custom UI action on the sys_email table called "Reprocess This Email" which updates the email and triggers the Reprocess Email event; Whenever an ITIL worker reviews an email, all he/she has to do is to choose either to create or update a ticket and click the "Reprocess This Email". Then Business Rule modifies the subject of the email by prepending the ticket number and then the Inbound Action uses the new subject to match the email with the ticket.
• I also created a script include which is called form the Inbound Actions. What it does, is to call some SOAP web services against the Exchange EWS in order to manipulate the email inside the shared mailbox (introduce the ticket number in the email subject and move the email to a designated folder upon processing done on Service Now side).

Cheers

[Jim Coyne]

Remember to tag the correct answer (even if your own) and any that were helpful.