How to launch Catalog Items from Email

[Uncle Rob]

But... but... #KillEmail

Yes, kill email when you can. In reality, Some systems and processes may still have components depending on an email initiation.   Here are some examples from my own history.

- support@company.com, service@company.com, contactus@company.com etc addresses that are externally facing need workflow driven responses.   (this is common in the hospitality space)

- legacy system is a starting point and has no rest/soap integration capabilities

- highly specialized staff that, for cultural or practical reasons, only uses email + 1 or 2 specialized tools (traders, field service staff, doctors, lawyers, etc)

Sometimes we have no choice in our inputs, and its better to win small than not win.

Before We Begin

• Understand Inbound Email Actions, especially Section 6, which outlines how to handle email variables.
• Understand Service Catalog Script API.   For further research, you can look at the Script Include "Cart" on your dev instance.
• It is advised that you create your own email address in your environment to handle the intake.   In my example I created "term@company.com".   We ended up creating this such that anyone emailing the address was also sending to company@servicenow.com without realizing it.   In this fashion both the original sender & term@company.com are retained.   A further benefit is you can make separate addresses per workflow you wish to trigger.  
• Text analysis is your enemy.   As much as possible ensure that your sender automated, not a person.   If that's not possible, resist attempts to make programatic decisions based on user entered email text.

Example:   Email initiated Termination

I've already created a Catalog Item with 3variables: terminee, subject, emailbody (HTML)

I'm assuming that whatever person / system sending will include in the body "priority:high" if priority needs adjustment.

Its also important to note that I don't generally use the request layer, so I will *also* want to modify the sc_req_item

Inbound Action

Name:   Email Based Term

Target Table:   Requested Item [sc_req_item]

Type: New

Order:   Anything lower (numerically) than your existing Incident items

Condition: email.recipients.toLowerCase().indexOf("term@company.com") > -1   (checks to ensure its coming to the controlling email address)

createRequest();
function createRequest() {
   var cart = new Cart();   //calling the cart API
   var item = cart.addItem('eb89a3b937e7d200a2982863b3990eab');   //sys_id of the catalog item I want to fire
   cart.setVariable(item, 'subject', email.subject) //sets catalog variable to the email's subject
   cart.setVariable(item, 'emailbody', email.body_html);   //sets catalog variable to email's body
     var rc = cart.placeOrder();   //this launches the catalog item, and creates a request object.   rc = the request object
   updateRITM(rc.sys_id);   //call a function immediately to update the ritm.   This must be a nested function, otherwise inbound actions get weird.
           //also, we're passing the sys_id of the request so we know what RITM to grab.
}
function updateRITM(req){
   var ritm = new GlideRecord('sc_req_item');
   ritm.addQuery('request', req);   //req is what we passed from the previous function. the sys_id of the request.
   ritm.query();
   while (ritm.next()){
       ritm.u_customer = gs.getUserID();   //my ritm table separately tracks its own customer, since I don't use Request
       ritm.description = email.body_text;   //we're still in the inbound action so why not exploit?
       ritm.priority = email.body.priority;     //good example of how to exploit email body variables
       ritm.update();
   }
}
event.state="stop_processing";   //stop evaluating inbound actions. This is why I keep this record's order lower than my incident from email rules.

Key Take-Aways

• It is possible, and even handy to trigger workflow from email
• if you want to modify RITM post insert, use a nested function where-ever you're calling the Cart API
• Make sure inbound action(s) evaluate before your Incident creation inbound actions
• Use stop processing once the script is complete.
• Don't be afraid to exploit email.body.variables... especially if the email source is automated.