Thought I would share this with the community in case it comes in handy for someone else.
One of the common things I've seen requested across clients is how to handle a number of different inbound emails from users or other systems. Typically each will have it's own unique twist, like needing a different assignment group, CI, priority etc.. I've seen this handled many different ways, some as basic as just creating additional inbound actions on the table and giving it some condition like "email.subject.toLowerCase().indexOf("solarwinds) > -1;". Or, I've also seen large switch statements in the Create Incident inbound action to account for this with the same sort of logic.
Other places, I've seen a custom table be created where you can enter subject or body keywords, as well as fields to set on the target record, like the incident short description or CI for example. After updating the inbound action script we can map the various values, but again we have to recode all the matching conditions and it's not super friendly, plus while closer to what I wanted, this might still need a fair bit of development changes if we wanted to add handlers for additional target fields, as well as changes to the inbound action script itself.
I figured there should probably be a better way to do this, and I after I stumbled upon this video ( TechNow Episode 12 | Condition Fields - YouTube ) I figured I could probably use something similar to do what I wanted. Here is what I ended up with:
First, I created a new table to store the rules, and dropped in a condition field that points to the sys_email table as outlined in the video. This let me build my match conditions on the inbound emails without having to code very much, you can add as many body, subject, or user criteria as needed. Next, I dropped in a reference to the sys_template table, which I figured I could use to apply to the target record to set the values I wanted. Again this was just to avoid hard coding things, if needs change you can just update the template. Here is a screenshot of the rule table for reference:
The last part I needed was just a way to tie them together. It actually turned out to be a pretty small code snippet that I dropped in the Create Incident inbound action. They cover the GlideFilter call in the video, again it's really cool if you haven't seen it yet.
//Inbound action rule matcher
var rule = new GlideRecord('u_inbound_action_rule');
//look for active rules on the same table this action is set to run on
rule.addQuery('u_active',true);
rule.addQuery('u_table', current.getTableName());
//sort the lowest order first, its possible more than one rule may match
rule.orderBy('u_order');
rule.query();
//loop through matching rules
while (rule.next()) {
var match = GlideFilter.checkRecord(sys_email, rule.u_condition); //true if the email meets the rule conditions
if (match == true) {
current.applyTemplate(rule.u_template.name); //apply the specified template
break; //stop processing, we only want the lowest order match to be applied
}
}
This got me pretty close to what I wanted but it's not without limitations. I haven't found a way to smoosh this all into one inbound action to cover all potential target tables, it still needs one inbound action defined for each table. Also, the condition builder strings are Case Sensitive, I haven't found a way to make it case insensitive either.
I hope someone may find this useful. If anyone has additional tips or tricks on how they've handled these needs in the past I'd love to hear them.
