Ordered Email Processing

From ServiceNow Wiki
Ordered Email Processing
Jump to: navigation, search
Notifications
Knowledge.gif Get the Book


Contents

1 Overview

The Order Email Processing plugin, available in the Aspen release, enables an administrator to configure a processing order for inbound email actions. In addition to forcing email actions to run in a prescribed order, the administrator can add a command to the script for an action that halts processing after the script runs.

2 Activating the Plugin

The Ordered Email Processing plugin is enabled by default for all new ServiceNow instances and can be installed by a user with the admin role for upgraded instances. See Activating ServiceNow Plugins for instructions on enabling plugins.

3 Configuring Processing Order

  1. Navigate to System Policy > Email > Inbound Actions.
  2. Open an existing inbound action or create a new one.
  3. Complete the form and assign an order number to the Order field to establish when this inbound rule should run in relation to other rules.
  4. To stop rule processing when an inbound email action runs successfully, add the following line to the bottom of the script:
    event.state="stop_processing";

    Inbound_Email_Actions_Order.png

4 Use Cases

4.1 Multiple Filters

Use process ordering and the stop_processing command to manage multiple filters in inbound email actions. In this example, we want to create new problem records when prb: appears in the subject line and new change requests when chg: appears in the subject line. All other emails are used to create a new incident. The actions are set up as follows:

  1. Create an action with a condition of Subject > starts with > chg: and the event.state="stop_processing"; command appended to the script.
  2. Assign this action an Order value of 100.
  3. Create an action with a condition of Subject > starts with > prb: and the event.state="stop_processing"; command appended to the script.
  4. Assign this action an Order value of 200.
  5. Create an action for incident with no conditions and an Order value of 300.
    It is not necessary to add the stop_command to the script for the incident action unless we want processing to stop at this rule to avoid continuing to another action.

Result: If either a change request or a problem is created, the stop_processing command stops processing, and no incident record is created. If neither a change request nor a problem is created, the inbound email action for incident creates a record.

4.2 Deleting Spam

In this scenario, we want to delete inbound emails identified as spam or emails from unknown users before they create an incident.

  1. Configure a rule with a condition that identifies emails as potentially containing spam or sent by unknown users.
  2. Assign this action an Order value of less than the smallest order number (the default is '100)'.
    This order number ensures that these conditions are evaluated before an incident is created.
  3. Add the stop_processing command to the script.
    This prevents subsequent actions from running if the conditions evaluate to true.
  4. Create an action for incident with no conditions and an order value of 200 or a number larger than the rule that contains the "stop_processing" command.
    If we want to stop processing when the incident is created, we add the stop_processing command to the script.

Result: If the email is spam or from an unknown user, the email is deleted, and no incident is created. If the email is not spam or is from a known user, then an incident record is created.

Was this article helpful?
Yes, I found what I needed
No, I need more assistance
Views
Personal tools