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.