One Field Shared Between Many Tables

//One Field Shared Between Many Tables

One Field Shared Between Many Tables

O
ne common problem I encounter with ServiceNow 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.

If there’s a central theme to all of these scenarios it is that you need to pay very close attention to what you’re doing when you personalize the dictionary, label, or choices for any field on an extended table. Chances are that the field you’re personalizing is shared between other tables and you’ll end up impacting another area of the application. Hopefully if you do it’s intentional :).

1- Mandatory fields:

Although there is a checkbox on the dictionary table to make a field mandatory, it should be used ONLY when the field in question should always be mandatory in every situation for every table that uses the field. As this is very rarely the case, it’s usually much more effective just to make the decision early on to use UI policies or Client scripts to make the field mandatory when it should be.

2- Read-only fields:

See #1. The solution to this problem is a little bit different though. Because security in ServiceNow can be applied in a few different ways, you’ll want to make sure to evaluate the options closely. Most of the time, Access Control Rules are your best bet through the System Security application. Depending on the situation (and how critical it is to secure the field in question) you may want to use a UI policy or a Client script to restrict access to the field. Just remember that UI policies and Client scripts only secure an object when it is loaded on the form which may leave your field open via list editing or some other method.

3- Reference qualifiers:

If the field in question is a reference field, then it’s very likely that you’ll end up using a reference qualifier to filter the records presented by the field at some point. If the tables sharing the field don’t all need the same reference qualifier (or if some don’t need one at all) then you’ll want to use an advanced reference qualifier. Constructed properly, an advanced reference qualifier gives you the ability to identify the querying table before reference qualifier is returned. This means that you can give each table its own reference qualifier, or no qualifier at all. Here’s a sample script that could be used for a Configuration item field shared between various task tables.

function myRefQualFunction() {
   var answer;
   switch (current.getTableName()) {
      case 'incident':
         answer = 'sys_class_name=cmdb_ci_computer^ORsys_class_name=cmdb_ci_service^';
         break;
      case 'problem':
         answer = 'sys_class_name=cmdb_ci_server^';
         break;
      case 'change_request':
         answer = 'sys_class_name=cmdb_ci_service^';
         break;
      case 'change_task':
         answer = 'sys_class_name=cmdb_ci_service^';
         break;
      default: answer = '';
   }
   return answer;
}

4- Labels:

This isn’t a dictionary setting, but the concept here is the same. Before you go and personalize the label for a field, you really need to be aware of all of the places that field is used. Changing the label of the ‘Configuration item’ field on the Incident form to ‘Incident CI’ would work great for incidents, but not so great for Change requests. It is possible to set up a separate label entry for the same field on each individual extended table.

5- Default values:

Setting multiple default values for extended tables has now been made much simpler (as of the Spring 2010 Stable 2 release). The solution outlined below is no longer necessary for instances running on Spring 2010 Stable 2 or later. See here for details on Dictionary Overrides.

There’s only one place to set a true default value for a field…the dictionary entry for the field. Client scripts can set default values, but that value is only applied when the form loads for a particular record. Here’s a script that I’ve used before to set different default values for the ‘State’ field on the Task table. You would place this in the ‘Default value’ field on the dictionary entry of the field in question.

javascript:
switch (current.getTableName()) {
   case 'incident': '1'; break;
   case 'problem': '2'; break;
   case 'change_request': '1'; break;
   case 'change_task': '-5'; break;
   default: '1';
}

6- Choice lists:

It’s very easy just to right-click on a choice field and select ‘Personalize choices’. While this option is very simple, it doesn’t always supply you with all of the information you need to make an informed decision about how and where the choice should be added. By selecting ‘Show choice list’ you can see exactly how the choice list is set up for all tables involved. Personalizing choices for a choice field is very straight-forward, you just need to be sure of the scope of the choices you are personalizing. A ‘State’ value of ‘Pending acknowledgment’ may make perfect sense in the Incident world, but might not be useful or needed for a Change task. Fortunately, you can specify unique choice values for each extended table that shares the same field.

About the Author:

Mark has worked in the IT industry since 2002 and with ServiceNow since 2007. He is the founder and creator of SN | Guru and the co-founder of Crossfuze, one of the worlds leading ServiceNow consulting partners. Prior to co-founding Crossfuze, he worked for ServiceNow as a Senior Architect on the Professional Services team. He has personally led dozens of successful implementations encompassing every part of the ServiceNow platform. He is also responsible for designing and developing groundbreaking ServiceNow solutions and best practices in the form of various applications, turnkey solutions, and integrations during his tenure at ServiceNow, Crossfuze and, of course, SN | Guru. These solutions are used today by ServiceNow administrators and consultants alike in hundreds of ServiceNow instances around the world!

8 Comments

  1. Brian Broadhurst January 1, 2010 at 6:46 am - Reply

    Very useful information – I’ve come across these issues in several implementations, and I’ve probably used each of these techniques at some point – although my javascript is not as elegant as the examples you give! I find that the issue usually arises when an organization takes a phased approach to implementing SNC. They would normally start with Incident Management, and unless you understand these issues, the temptation is to configure the dictionary settings to fit phase 1 – then when you come to implement phase 2 – maybe Change Management – you find that you have painted yourself into a corner, and you have to undo and re-do a lot of work.

    Brian

  2. Mark Stanger January 4, 2010 at 10:46 am - Reply

    Thanks for the feedback. You make an excellent point that this often gets overlooked because people aren’t implementing incident and change at the same time. You’ve definitely got to keep this in mind whenever you implement any of the task disciplines.

  3. Lam Hoang January 27, 2010 at 1:31 am - Reply

    Hi Mark thanks for the great info.

    I was wondering if there’s is an option to rename the labels from the task table in several forms.

    So the task label of number is: number. In Incident I want to use task.number and rename the label to Incident number. And for Problem I want to use task.number and change the label to Problem number.

    Is this possible?

    • Mark Stanger January 27, 2010 at 1:36 am - Reply

      Thanks. I’m glad you found it! It is possible. Check out the article I linked to under point #4 above.

  4. Rick Mann January 28, 2011 at 3:42 am - Reply

    Excellent info, exactly what I needed. Thanks.

    Rick

  5. Elvis May 8, 2017 at 1:12 am - Reply

    Wow – these articles are old, but-still; extremely useful information!

    Thanks!

    • Mark Stanger May 8, 2017 at 3:29 pm - Reply

      You’re welcome!

  6. Naveen Dubey May 18, 2018 at 8:53 am - Reply

    Very useful article. Thank you Mark !! 🙂

Leave A Comment