Working with State (or other choice lists) in ServiceNow
October 29, 2012, 12:42 pm - James Farrer
A few days ago I ran into a problem again and in trying to understand it better Mark Sandner and I did some testing and found out how to make changes to the options so that other tables are not affected.
So a little background on what's going on. When working with choice lists (a.k.a. drop-downs) for extended tables the options can be shared from the top down. One of the biggest examples is the State field on the task table. Having this field in common across all task tables makes a ton of sense, but having the values be the same usually doesn't. Sometimes you'll want Work in Progress, sometimes you just want Open. Pending only applies to some circumstances.
The way the choice fields are set up the extended tables can have their own options for the drop-down. The issue is that if you just take the options that are used on the task table and move them over in the sluchbucket then it deactivates the option for all tables that are using it.
The good news is there's an easy way to work around this issue.
If before deactivating anything you first add a duplicate option that is specific to the table, then the system will duplicate all of them, but specific to the table so you can then safely deactivate or change them as needed.
So first add a duplicate option, I used "Open" with the value of 1 like this:
Then save the options with it showing a duplicate.
When you save the changes it will create the duplicates. Then the next time you go to Personalize the choices it will show the same options, but this time they will be specific to the table and you can deactivate them, change them, or add new ones without causing a problem to other tables.
Client Script Messages in ServiceNow
October 23, 2012, 1:44 pm - James Farrer
Right now I'm working with a client that has to support two different languages in their ServiceNow instance. Because of this I have been thinking more about using Messages. One area in particular that is relatively new and not often understood is Client Script Messages.
Until late last year javascript alerts and other info or error messages used in client scripts were difficult to translate. Now there is a new field on the Client Script form called Messages. When I first saw this it didn't make a lot of sense to me, but after having used it a little I'm getting to be a big fan. Any time content can be separated from function it typically means less maintenance for the code.
The Messages field provides an easy way to access the System UI -> Messages table in Client Script. On the server side we've been able to do this by calling gs.getMessage("sample message"). Now in a few easy steps in a client script you can do it easily there too.
To set it up you put the key for any message that needs to be displayed in the script into the Messages field (one per line) and then when the form is loading those messages are looked up in the proper language in the Messages table and sent to the client along with the script so they are available. Then in your client script you can just call getMessage('message_key') to use the message.
If you don't want to mess with the Messages table while you're scripting then you can just put your message in as the parameter to getMessage and it will return the text as entered if it doesn't find anything in the Messages table that matches. I prefer putting a more descriptive name instead of the actual text but either way works.
Controlling Reference Field drop-down order in ServiceNow
October 19, 2012, 2:02 pm - James Farrer
I just spent a bit of time trying to change the order for the options in a reference field that is displayed as a drop-down. I was just about to give up when I ran into an attribute that appears to be just for this scenario.
The options are sorted by the display value by default. In this case I needed to order by another field. It turns out the secret is to add the "ref_sequence" attribute.
So if you wanted to order by an "order" field, you would add "ref_sequence=order". Simple but obscure.
