Table User[sys_user], field Country code[country], Table Location[cmn_location] field Country[country], Table Company[core_company] field Country[country] -> defined as string instead of reference

michaelsch_fer
Kilo Contributor

Table User[sys_user]
Country code[country] is defined as string
In choice list there is an incomplete list of choices (9 country codes and one invalid? entry:
Label: javascript:'System (' + GlideLocale.get().getCurrent().getCountry() + ')'
Value: NULL_OVERRIDE

Table Location[cmn_location]
Country[country] is defined as string
In choice list there is an incomplete list of choices (9 countries)

Table Company[core_company]
Country[country] is defined as string
No choice list

Wouldn't it be better for  all three  above mentioned fields to define them as reference fields towards table Country[core_country]?

Table Country[core_country]
has got all fields 'display' attribute set to 'false'.
I propose to set for field Name[name] display to 'true'.

With referencing to Country table other attributes (like ISO-2 country code, ...) can be made available in views and reports easily.

Does anybody know why these fields are defined as String instead of Reference to table Country[core_country]?

Has anybody changed from String to Reference and made better experience with that?

With kind regards

Michael Schäfer

1 ACCEPTED SOLUTION

bernyalvarado
Mega Sage

Hi Michael,



Indeed it will be better if all country fields are actually a reference to the core_country table.



What you currently observe on your instance is just a reflection of the evolution of "changes" on different versions of ServiceNow. Architecturally wise it could make sense to change all these country fields to be a reference of the core_country table, yet, ServiceNow will shy away of enforcing such change on all customers since it could break some existing customer implementations.



Still, you can go through some refactoring with a little bit of customization if you will like and you could get out some benefits on standardization and data cleaness that should help at the time of reporting or any other business logic that depends on the country field.



Thanks,


Berny


View solution in original post

5 REPLIES 5

bernyalvarado
Mega Sage

Hi Michael,



Indeed it will be better if all country fields are actually a reference to the core_country table.



What you currently observe on your instance is just a reflection of the evolution of "changes" on different versions of ServiceNow. Architecturally wise it could make sense to change all these country fields to be a reference of the core_country table, yet, ServiceNow will shy away of enforcing such change on all customers since it could break some existing customer implementations.



Still, you can go through some refactoring with a little bit of customization if you will like and you could get out some benefits on standardization and data cleaness that should help at the time of reporting or any other business logic that depends on the country field.



Thanks,


Berny


bernyalvarado
Mega Sage

Interesting enough we actually are in the process of implementing a little bit of this refactoring to switch country string fields into reference fields to the Country table. Feel free to email us at balvarado@volteo.com and/or asmith@volteo.com and we will gladly share our experience with you.



Thanks,


Berny


bernyalvarado
Mega Sage

Hi michaelschäfer, do you have any further questions? Do you believe you can mark the responses as helpful/correct so that we can close this thread?



Thanks,


Berny


Hello,


I just sent you a mail message to gain some experience from your adaptions.


At least I want to apply the changes, but before I must be able to judge the risk of upcoming releases not overwriting the customization.


For ServiceNow community it would be interesting that we show with one example how such a field change --> reference to table can work.


with kind regards


Michael S