For years, I’ve been a big proponent of service oriented architectures.  I got started with them back in the early 2000’s from a business application perspective and always thought they would/should apply to the creation of IT services as well.  With recent advances in the service catalog space that have been made  with tools like ServiceNow, we can now start applying some of these same principles to IT.

The ServiceNow service catalog can more accurately be thought of as a service request catalog, since it is primarily used in conjunction with the content management system (aka CMS) for displaying the items that can be requested by your customers.  It does not actually provide a means to dynamically look-up and resolve back-end service endpoints (i.e. REST or Web Services), but does provide a great deal of functionality. This functionality is enhanced with its ability to create sophisticated routines to process and route requests and its integration into the ServiceNow workflow engine.

This article will be the first of several in which I’ll review a method of creating ServiceNow service catalog items that I call Action Based Services.  There are many ways to create a “service” in ServiceNow, some better than others.  The idea of action-based services is to avoid a classic pitfall where you end up with 100’s or 1000’s of “services” in your catalog, making it nearly impossible for customers to find what they are looking for and just as impossible to maintain.

Action-based Services, at their core, encapsulate multiple, similar request types under a common ServiceNow catalog definition.  As an example, let’s say I need a set of functionality that would manage assignment groups in my ServiceNow instance.  If we start with the basic CRUD (Create, Read, Update, Delete) functionality and create a unique ServiceNow catalog item for each of them, I will have 4 unique items that I need to maintain.  Now, its unlikely that the basic CRUD functions will be sufficient and there will likely be nuisances for activating and deactivating groups, adding and removing members, etc.  If each one of these is a unique catalog item, not only do you end up with a dozen or more entries in the service catalog, you have that many items to manage and maintain.  Additionally, each catalog item will potentially have its own set of variables, client scripts, ui policies and workflows.  What action-based services does is merge all this similar functionality into a single catalog item which then uses a special variable (the Action) to make choices within its execution to manage the different sets of functionality while enabling a greater degree of reuse between the functions.  Along with the Action, the other key components that pull everything together are catalog UI policies and catalog item workflows.

In the next set of articles, I’ll walk through the initial setup of an action-based service, using the ‘action’ in combination with UI policies to dynamically render a request form and finally, implement a workflow that will serve as the backbone of the service and manage the flow of activities based upon the selected action.