This is the last segment in a four part series of articles focused on using ServiceNow to create richer services in the service catalog. In the prior segments, we discussed what an action-based service is, built the core structure of the service and then used that core structure to create a dynamic rendering of the request form based on the selected action. The first 3 segments gave us a working (albeit limited) service. The missing part that really brings it all together is adding workflow functionality. In this segment, we will create a workflow that uses the value of the action variable to determine which course of action should be taken. It will then manage that service request ticket through completion, including notification to the user.
Action Based Service Automation – Dynamic Forms (Part 3)
In the last article, we discussed the basic setup for an action-based service. This time, we will be focused on using the value of the action variable to determine which variables should be displayed or hidden on the form. The primary tool for driving this capability is the use of catalog ui policies. If you are unfamiliar with catalog ui policies, the ServiceNow wiki provides a good overview. The catalog ui policy is going to allow us to specify when a particular variable should be displayed or hidden based upon the Action selected.
Action Based Service Automation – Setup (Part 2)
For the second part of this series, we’re going to focus on creating a new service in the ServiceNow service catalog and reviewing the core foundation we will use to create an action-based service. Action-based services in ServiceNow are created in the same way you would create any service catalog item.
Rather than just discuss the steps theoretically, we will build a basic service. The service will be a generalized I Need Help service that will allow the user to choose from a variety of options (Actions) to narrow down the type of help they need. Depending on the option selected, the form will dynamically display fields to capture more specific data and will in turn route the ticket to an appropriate group for fulfillment.
The key things to focus on is that we will be creating a single service to handle multiple support requests. This will allow the user to go to a single service and have the service guide them, rather than hoping they have selected the correct support service from a list of many and will be able to collect the specific information necessary for the fulfiller to complete the task without having to engage in a back-and-forth conversation with the user (thus elongating the fulfillment time)
Action Based Service Automation – Overview (Part 1)
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.
Testing Workflows Without Publishing
If you look at the ServiceNow wiki, you would expect that you need to publish a workflow before you can test. Well, that is not entirely true and those that have worked with ServiceNow for a while have likely already discovered this is not always the case. If you are the user that has the workflow checked out, when you execute the workflow, you will see the new (un-published) version execute. This is very useful as you can make small changes and test without creating hundreds of versions of the workflow (as a result of the publish action). While very useful, its important to remember that if you are having someone else perform testing of your workflow, you MUST publish the workflow or they WILL NOT see the changes you’ve made.
Dynamically adding variables to a request item
Whatever your reasons may be, there may come a time when you need to dynamically add an additional variable to a request item after the original request has been entered by the user. This could be for populating additional information that is not available at the time the request is made or if you are breaking up a single request that contains a list into multiple individual requests that can be operated on individually.
The challenge with doing this is that there is a relationship between four different tables that needs to be setup to ensure that the variable is associated with the request properly. At the top is the Request Item table itself (sc_req_item). Ultimately, this is where the variables will be referenced on any subsequent form displays. The other three tables create the relationship between the request item, the questions and the answers. These other tables are sc_item_option_mtom, item_option_new and sc_item_option.