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.

Continue reading

Building Script Libraries

In the time I’ve been working with ServiceNow, I’ve seen a lot of people using Script Includes to develop code that, in theory, will be reusable.  This is a great thing.  However, if you don’t pay attention, the number of script includes quickly becomes overwhelming and you loose track of what you (or someone else) has developed.  As a result, its not uncommon to have numerous routines that essentially perform the same set of functionality, but because they were unknown by another developer in the system, it went un-reused.

What I’ve found very useful is to put some structure around the creation of your Script Includes to encourage reuse and make it much easier for other developers to find routines that could help them.  First, I’ll highlight what a typical Script Include looks like and then transform that into a structure that allows for both server-side and client-side calls to be made to a common library of functions.

Continue reading

Hiding empty variables on an approval form

If you have created a service catalog item that has an associated workflow, you may have found that all variables captured on the request are displayed on the approval form in the variable summary section.  Depending on how the catalog item is constructed, there may be a number of variables that you don’t want to be display or are simply empty because the fields were not relevant for the particular request.  There are two solutions to this based on if a field should never be displayed in the summary or only displayed if it is not empty.

The first case, when a field should never be displayed, is pretty easy.  By default, the form to manage a variable on a catalog item, does not display the option “Visible on Summaries”.  To enable this, you will need to Personalize the Form Layout of the Variable item view and move “Visible on Summaries” to the Selected side of the slush-bucket.  By default, this field is selected for all variables.

Continue reading