During a recent service-based ServiceNow implementation, I used the out of box Ticket table and have realized most people aren’t even aware it exists.  There is a wiki article that covers it a little bit (http://wiki.servicenow.com/index.php?title=New_Ticket_Module), but states you need to activate the “Domain Support - MSP Extensions plugin” plugin which is NOT entirely true.  This plugin should ONLY be activated when working with an MSP client.  In order to use the Ticket table for a non-MSP client, all you need to do is create a module pointing to that table.

Why use the Ticket table?

When an implementation contains multiple functional areas of an organization such as IT, HR, Finance, etc., it is beneficial to create some record to track basic information about an interaction with a customer before determining what type of record it will eventually become.  Then as the agent works with the caller or is triaging an inbound email in ServiceNow, they can choose the proper Business Service and Symptom which auto-routes the case and creates the proper type of record.

As you can see from the screenshot above, an agent or an inbound email would populate a few fields about who the caller is and whatever other pertinent is necessary.  Then an agent would select the proper Business Service & Symptom which then routes it to the proper table whether that be an IT Incident, HR Case, Facilities Request, etc and passes the information along when they hit the "Next" button.

The "Next" button is really where most of the functionality for this exists since the Ticket table is an out of box table and extends Task.  The "Next" button obvoiusly takes into account what the agent selected for the Business Service & Symptom to create the proper type of records but it also must copy not only all the details of the Ticket to the record it will eventually create as well as any attachments that were added by an agent or inbound email.

This snippet allows you to create a downloadable file and override the name to whatever you want in a Processor.  I found this handy for creating downloadable JS files, not something you can typically do since the js file extension is handled, presumably by the web server.

// Setting the content type to app so it just downloads instead of displaying
g_response.setContentType("application/octet-stream");

// Set the Content-disposition header and set the filename to whatever
g_response.setHeader("Content-Disposition", 'attachment; filename="whatever.js"');

// Write out some stuff
var writer = g_response.getWriter();
writer.write( "Some stuff....." );

For this processor I just set a parameter of JS. When I hit instance.service-now.com?JS it downloads "whatever.js" with my content!

I recently had a client that had 50+ different email aliases that they planned on pointing to ServiceNow to create different types of records and wanted each assigned and categorized differently based on what email address the email came from.  To prevent the inbound action from becoming unmanageable and hard to read, I decided to build a table called "Inbound Action Definitions" that the inbound action references when creating incidents.

From the screenshot below you can see that it takes a few things into consideration:

• Email address the email was sent to initially
• Active flag
• Type of record to be created
• Values to insert for fields

This in turn takes certain values from the email itself of from the Inbound Action Definition record and creates the proper type of record.

When using multiple global UI Scripts it may become necessary to have those scripts load in a specific order.  I have been using this very simple solution to force scripts to load in a specific order.

First, add an Order field to the table.

Next, add an before query Business Rule to the UI Script table with the following script.

current.orderBy('u_order');

Last, set the order of the scripts.  For out of box scripts I will usually set these to 0.  jQuery will usually be set to 100 and anything that depends on jQuery will be set to 200 or higher.