TUESDAY, FEBRUARY 07, 2012

Posts Tagged ‘Variables’

S

ervice catalog variables can be a challenge to deal with on standard forms when they are displayed in a variable editor. I’ve written before about different ways that you can solve one of these challenges…making the variables read only, so that they can’t be modified after the initial submission through the service catalog interface. Another common problem I’ve seen is that you can end up with a lot of variables that end up empty in the variable editor on your request item or task because they were optional or hidden on the front-end catalog form. If the variables are empty and you aren’t going to have users interact with them on the standard forms then there isn’t much use in having these variables show up at all in the variable editor.

Until now there really hasn’t been a good way to deal with this issue because of the challenges of dealing with so many different variable types in client-side JavaScript. A couple of days ago one of my colleagues, Jacob Kimball, suggested to me that we might be able to overcome this issue by using a ‘display’ business rule to collect the blank variable information at the server and then pass those variable names to the client. So, you can thank Jacob Kimball for the brilliance of this solution. I’m just spreading the love. :)

Learn more ...

M

andatory fields are usually pretty simple to work with. Service-now provides simple UI policy and client script methods to make fields and variables mandatory. You may have noticed as you have worked with checkbox variables in the service catalog that these methods don’t apply. The reason for this makes perfect sense if you think about it. A checkbox has only two possible values…true or false. When the checkbox variable loads it is already set with a value of false (unchecked). Because of this, there’s never a situation where a checkbox variable wouldn’t satisfy a mandatory check. It will ALWAYS have a value!
What people usually want in these scenarios is to require a user to select a minimum number of options from a certain group of checkbox variables. In these scenarios, this minimum number of items checked really represents the standard for a mandatory check for that group of checkboxes. There’s not a simple way to handle these situations, but I’ve set up some client script solutions that allow you to perform this type of validation if it is needed.

ServiceNow Mandatory Checkboxes

Learn more ...

I just learned something new today about working with checkbox variables/questions in Service-now.com. Even though I’m probably one of the last people to figure this out, I’ll post it here so at least I can find the solution again when I need it!
Service-now allows you to set up variables or questions for use in data collection when working with Service Catalog or in Surveys. One of these variable types is the checkbox variable. The way that these variables works has always bothered me. The problem I’ve always had with them is that the system wants to group them all together and gives them a generic label of ‘Options’ when they are presented on the screen like this…

There are a couple of things I don’t like about this arrangement. First, the ‘Options’ label just looks bad. I’d really like to change that name to something else. Secondly, just because they follow each other in order doesn’t mean that I want to have all of those checkboxes grouped under a single question when presented on the screen. They might be asking completely different things. Well, it only took me 3 years but I’ve got a solution now that requires nothing more than a little bit of care in the arrangement of a few variables on your catalog item or survey. :)

Learn more ...

Choice lists are one of the basic input elements available in Service-now.com. They are very simple to personalize and add or remove any options you need for your application. Something I see fairly often is the need to use the EXACT same choices in different tables that may not be directly related as extended database tables. Another scenario is where you have a choice list defined on a standard field and you want to use that same field and its choices in a service catalog ‘Select box’ variable. Service catalog record producers often have this requirement. In these cases, you may be tempted just to manually re-create the entire list of choice list options for the new field or ‘Select box’ variable. As long as the lists are the same, you can save yourself some setup time (not to mention the ongoing headache of maintaining the same information in 2 places) by making use of the ‘Choice table’ and ‘Choice field’ options.

Learn more ...

A

while ago I helped to answer a forum posting for someone who was looking for a way to present catalog variables to an end-user on a Request Item form but restrict the editing of those variables. At the time, I came up with a solution that worked, but that I really wasn’t happy with. I recently came across another forum posting where the poster wanted to do something similar. The difference for the most recent poster was that the variables were to be shown on an Incident form (which had been generated by a record producer). There were some subtle differences in the way variables were presented on the different forms that made my original script unusable for the incident form. So, I’ve had to revisit this topic to come up with a better solution and I’ve decided to compile all of the different options for making variables read only on a regular form. These solutions can be used in a variety of places, but will most often be applied to the Catalog Item, Catalog Task, Incident, or Change Request tables. Enjoy!

Learn more ...

Latest Comments

  • Mark Stanger: This functionality doesn’t connect to an FTP server. See this line in the post above…...
  • Mark Stanger: The report page is back-end XML so there’s no way to directly manipulate the behavior of that...
  • Mark Stanger: Due to some ServiceNow limitations, the localhost MID server option had to be removed.
  • Matt Haak: Is it possible to use this with the local Mid Server (mid.server.localhost) It appears from this community...