Posts Tagged ‘Dictionary’
Posted by Mark Stanger in System Definition Tuesday, 6 April 2010 07:11 4 Comments
W
hen working with reference fields, it is really important to understand how the display value for the reference field works. The display value for a reference field is what the end user actually sees when they search in a reference field to produce an autocomplete dropdown and what they can see when a reference field gets populated. Information about reference fields and reference field display values can be found here.
Some questions about display values that I hear very often are “How do I show information from more than one field for the display value?” or “Can I have different display values on 2 reference fields that reference the same table?”. The limiting factor when answering these questions is that you’re limited to a single searchable display value per referenced table. What this means is that EVERY reference field that references a particular table needs to use that table’s display value so you cannot mix and match between reference fields. There are a couple of options that can be used to provide a bit more information to the user in these scenarios however.
Posted by Mark Stanger in Scripting Tuesday, 19 January 2010 06:13 2 Comments
This customization DOES NOT come across in update sets! If you make this change you need to make it across all of your instances manually as soon as you verify the result in a dev or test instance.
S
ervice-now allows you to use and create extended tables to help organize your database structure. Out-of-box, there are 2 really important places that you’ll need to understand this setup. The first is the ‘task’ table (which includes incident, problem, change_request, etc.) and the second is the ‘cmdb_ci’ table (which contains every table in the Service-now CMDB).
One of the nice things about this type of arrangement is that it allows you to set up fields or columns on these tables that can be unique to a single table (‘caller_id’ on the Incident table) or available to all extensions of a parent table (‘short_description’ on the Task table). You can see if a table extends or is extended by another table by using the table schema map.
If you’re not careful when working with tables that are set up this way, you can get yourself into a little bit of trouble. Fortunately it’s not that difficult to work your way out of it most of the time. The biggest thing to be aware of when you’re creating fields on an extended table is to know what table you’re working on and what table(s) your new field should be available to.
If you do make a mistake, the easiest thing to do is just to catch it early and re-create the field. If that’s not possible then there is a command you can run that promotes a field from an extended table to a parent table. The function should be run from ‘System Definition -> Scripts – Background’ and works like this…
Posted by Mark Stanger in Client scripts Thursday, 7 January 2010 09:44 4 Comments
S
tring fields typically aren’t anything to get too worked up over, but I’ve discovered a couple of cool tips on dealing with string fields in Service-now.com that might benefit somebody else at some point.
The first tip is to know what the difference is between a single-line text field and a multi-line text field in Service-now. It’s obvious when you look at them, but there are some details under the hood that you might not know about. The driver of these differences is the ‘Max Length’ value that you set on the dictionary entry for the string field. Any string field with a max length value less than or equal to 255 will be rendered as a single-line text field. As soon as you hit 256 or more characters for the max length, the field is changed to a multi-line text field.
Posted by Mark Stanger in Scripting Thursday, 31 December 2009 17:06 4 Comments
O
ne common problem I encounter with Service-now deployments has to do with the sharing of a field between many tables extended off of the same parent table. Because the Task table and the Configuration Item table make heavy use of extended tables this is where I see the problem most often. What is the best way to make changes to a shared field for the table that I’m working on, but not impact other tables that may be using the same field?
Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.
Recent Comments