A while ago I wrote about some of the different ways to customize the autocomplete search behavior for a reference field. I saw a forum post the other day where the poster asked if it was possible to create aliases for records so that they could be searched on. For example, what if you had a CI called ‘ABC’ but everybody knew it by the name of ‘XYZ’? While support for this type of searching isn’t really built into Service-now, it is possible to add this kind of behavior to a reference field. If the CI just had a single alias, you could probably just customize the display value and do a ‘contains’ autocomplete search as described in the article previously. For this specific scenario I think that there might be a better way to accomplish the same thing.
This solution relies on 2 simple customizations. For the purposes of this article, I’ll assume that we want to provide aliases for a few of the records in the Configuration Item (cmdb_ci) table. The first step is to create a new field on the ‘cmdb_ci’ table called ‘Alias for’. This field should be a reference field to the same table you create the field on…in this case the field needs to reference ‘cmdb_ci’. The purpose of the field is so that you can create a CI record that has no other purpose other than to point to another CI record. Your alias becomes a CI and it points to the true CI populated in the ‘Alias for’ field.
Once you have the ‘Alias for’ field set up and you have an alias populated, the next step is to create a client script to populate the true CI value when an alias is used. In this case, we want to set up the alias functionality for the ‘Configuration item’ field on all Task tables (Incident, Problem, Change, etc.). Our client script should be set up on the task table with the following settings…
The purpose of the client script is to wait for the Configuration item field to change, check the populated CI to see if it has any value in the ‘Alias for’ field (indicating that it is just an alias) and populate the true CI value from the ‘Alias for’ field.
Name: Populate CI from Alias
Table: Task
Type: onChange
Field name: Configuration item
Inherited: True
Script:
//If the page isn't loading
if (!isLoading) {
//Hide any field message on the 'cmdb_ci' field
g_form.hideFieldMsg('cmdb_ci');
//If the new value isn't blank
if(newValue != '') {
//Check to see if the CI is an alias
var rec = g_form.getReference('cmdb_ci');
if(rec.u_alias_for != ''){
//Populate the value of the true CI
g_form.setValue('cmdb_ci', rec.u_alias_for);
g_form.showFieldMsg('cmdb_ci','CI populated from alias');
}
}
}
}
It seems like this could cause issues around reporting. By having alias CIs included on the same CI table, wouldn’t that skew your numbers for reporting total class counts? In particular, if it were used with active servers.
I suppose it could, but that could be easily circumvented just by labeling the alias CIs as such. Then you could simply filter them out in your reporting as needed.
Can this be done in a ui policy as well?
Yes! You can take the script logic above and use it in the UI policy script fields the same way.
Could these be excluded from being used in related lists like “Affected CIs”?
There are ways, but the only supported, documented way is explained in this SN wiki article. You can ignore the part about reference qualifiers for lists, that’s an error.
http://wiki.servicenow.com/index.php?title=Filtering_Related_List_Relationships#gsc.tab=0
Looking for a method to use an alias for Incident Business Services.
I was able to apply above method for using Alias’s on Configuration Items, and count about 5 steps.
Am trying to apply same method on Incident Business Services, but can’t quite get it functional.
Is there a written procedure anywhere for this?
Thanks
You should be able to use this exact same solution for any other CI type, including business services. The only step that would change is the final script (and then it would only change if the field you were referring to wasn’t ‘cmdb_ci’. If it is different, just replace ‘cmdb_ci’ with the name of your field and then have your client script run on change of that other field.