Research Hub > services > Inbound Action Items for ServiceNow: A Novel Solution to a Common ITSM Problem

April 27, 2021

Article
3 min

Inbound Action Items for ServiceNow: A Novel Solution to a Common ITSM Problem

Emails from outside sources do not need to create noise in your Incident queue.

Nate Engstrom

itsm

While working with one of my clients last year, we kept running into an issue that may sound familiar to others who use ServiceNow as their driver for ITSM. Here’s the situation: There’s noise flying around your system in the form of emails. For out-of-box (OOB) configurations of ServiceNow, almost all new inbound emails create an Incident record.

Learn how CDW can assist you with your ServiceNow needs.

A Common ITSM Problem

The problem is that there would be Incidents generated from an automated email via an inbound action. (see example below)

Note: The originating address for this email is from an automated process. The subject line from the email is going to consistently contain “New Server Built…” to start, followed by important information.

These emails would be assigned to the Service Desk by default, and it doesn’t take an ITSM expert to see that what’s being presented here is not an Incident. So how can we fix this?

The Solution

What I’ve come up with involves creating an inbound action that triggers before it hits the “Create Incident” inbound action. This action will order a hidden item from the Service Catalog and will provide the subject and body text for the incoming email. I call these hidden items “Inbound Action Items.” Here’s how to make one.

Step 1: Create Your ServiceNow Catalog Item

For the above example, I would name this Inbound Action Item “New Server Built – IAI.” These catalog items need two variables: single-line text to contain the subject line, and multiline text to contain the body of the email. Important to note: These items should not be available by any catalog or category, so leave those fields blank. Also, make sure that you have the User Criteria for “All Users” so that an outside system like no_reply@example.com can create these items. These users will show up as “Guest” in the Requested For field on the RITM.

Step 2: Create a Simple ServiceNow Workflow

For the above example, all that is required is a simple workflow that fires off of the table. In between the Begin and End blocks, insert a Catalog Task block. This Catalog task should be assigned to the team you want to know about the email. Don’t forget to associate this new workflow with the catalog item you created.

Step 3: Create the ServiceNow Inbound Action

For the above example, this is how I would build the Inbound Action record:

Important to note with the picture above: Make sure that the Execution Order is a number lower than your Create Incident inbound action and that “Stop Processing” is enabled.

In the actions tab, use the following script:

Note: There is a sysid on line 3. This is the sysid of the catalog item you have created. For best practice, you should have that sys_id be a system property that you call into the script instead of hard coding it. The attach function also attaches any attachments that are part of the email being processed.

Once all these elements are in place, the next time an email like the one above arrives it will no longer create an Incident. Instead, it will create a catalog item and task straight to the users who need to see it most: your service desk team, who already have enough to do as it is.