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.

Catalog UI Policy Setup

The first thing we are going to do is setup the catalog item form to access catalog ui policies directly.  We won’t need this until a later step, but this gets everything in place up front.  This is the easiest way to manage your catalog ui policies, however by default, catalog ui policies are not displayed on the catalog item form.  The catalog ui policies reference the catalog item so to add to the catalog item form we start by personalizing the catalog item related lists.   The available item we want to add is labled Catalog UI Policy->Catalog Item.  Once completed, your form should like similar to this:

Creating Variables

Now that we have the basics setup, lets get back to the service itself.  If you remember previously, we have only defined a single variable named Action.  We are now going to create the remaining variables needed for the different actions.  We have three actions (Password Reset, Application is not working and Help with something not listed).  There will be some common variables for all three actions and some unique variables for each particular action.  The following list shows the variables we will create:

Password Reset

1. Environment (Select Box) – Lab, Dev, Prod
2. User ID (Single Line Text)

Application is not working

1. Application (Select Box) – Word, Excel, Powerpoint, Other

Common

1. Description (Multi Line Text)

If you remember when we created the Action variable in the previous article, that variable was set to mandatory.  When creating these variables, they should all be set to not mandatory (the mandatory box should be unchecked).  We will handle making fields mandatory in the next step (Catalog UI Policies).

Once you are complete defining the variables, you list should be similar to the following:

If you click the Try It button on the catalog item, your form should now look like this:

Note: Since we have not yet done anything with our catalog ui policies, every field is displaying on the form.  Once we are complete, the only variable that will initially display on the form will be the Action field.  All the remaining variables will be hidden and only displayed at the appropriate time.

Catalog UI Policies

Our next step is to start creating the catalog ui policies what will govern our variables.  While we will be interacting with our catalog ui policies from within the service item itself, its important to remember that all catalog ui policies are stored in the catalog_ui_policy table.  So, to make it easier for some looking at entries in that table to get a better feel for what the entries purpose is, I like to use a descriptive name in the short description that includes both the service name and the variable it will be acting upon.

Lets start with our first service variable for the password reset action – Environment.  We are going to create a new catalog ui policy with the following information:

There are several key items to notice about this particular catalog ui policy.  We are specifically focused on the condition when the selected action is equal to Password Reset.  In this situation, we will act upon the environment variable by making it mandatory and making it visible.  You should also notice that the policy sets the Reverse if false option.  This option is key to our ability to show and hide particular variable items on the form.

I’m not going to go through creating a catalog ui policy for each of the variable since they are essentially all the same, with the only difference being which particular action should display the variable and which variable is being acted upon.  Once you are complete, you should have a list of 4 catalog ui policies:

One thing we didn’t touch on is the description variable.  If you remember, this variable is common to all the actions.  As a result, the catalog conditions on the policy need to specify it display on all the actions.

Another thing to note.  It might be tempting to combine both the userid and environment fields into a single catalog ui policy.  There is a very good reason why we don’t do this.  Lets presume that a future enhancement to the service adds a new action that will also use the environment variable.  Within a catalog item, if there are multiple ui policies that are acting upon the same variable, unpredictable results will occur.  There is no guarantee on the order in which the ui policies will fire so you can (and likely will) have situations where the variable is displayed and it shouldn’t be or isn’t displayed when it should.  By simply creating a unique catalog ui policy for each variable and managing the display of these variables using a condition based on the action field, we guarantee when the variable will and will not be visible.

If everything has been done correctly, when you click the Try It button on the service, you should see a screen similar to the following:

If you remember, this is exactly what our service looked like when we finished the Setup article.  The difference now, however, is if we select options from the Action field, we see the specific form variable required (and ONLY the specific form variables required.

We now have a functional service that can be used to collect information from the user and create a request ticket.  However, it will not do anything.  Of primary importance, the new ticket will essentially go into a black hole since it has not been assigned to a group to manage.  In the next segment, we will add a workflow to the service which will use the Action to route tickets to the appropriate group for processing and provide feedback to the user about their request.