So I wanted to cover a topic that I very briefly touched on in last weeks HR Academy session. In case you missed it, here it is:
* If you haven't yet seen it, be aware that I go through an awful lot of stuff in a very short period of time. So just be mindful that this is still very high-level and not everything is covered.
With that being said, i wanted to go into more detail about the subject of Solution Design. Especially when it comes down to features or functionality for people in other countries or in use with other languages.
A prime example is the KB example I use in our training course (available here) where I example how you could have a KB per region (if you so wished) and leverage a feature called "user" or "employee" criteria applied at the KB level, which would look like this:
The idea here is to show that, if we know our user / employee records are associated to a location, then we should be able to build a criteria around that relationship and apply that as a "can read" criteria to the KB in question - not to say you have to, it's just to say you can. So, in the example above anyone in the World can access the "Global" KB, people in the North American region can access both the "Global" KB and the "NA" KB, and people in Canada could access all 3.
Ultimately the design needs to fit the requirements and in the KB example it could be one KB with Knowledge Blocks in the articles or multiple KB's, however the take away is - be aware of what's possible and what you have available to your out of the box, whilst also leveraging data to do the work for you, making it a data driven solution rather than a code driven solution.
What if I said we also need to think about our coding logic as well?
The international challenge with Display Values
Now, let's imagine we have a Workflow, a Flow or a Business Rule (or any other type of scripted logic including Client Scripts) that relies on some sort of a GlideRecord query or record check to a table and does something like this:
var check = new GlideRecord('table');
check.addQuery('field', 'filter value');
check.query();
if(check.next()){
if(check.field.getDisplayValue('Yes')){
return true;
}
} Whilst this is a completely fictional piece of code, the problem is very real.
This will only work in English. And what I mean is, this piece of script will only work when executed by someone with an English language preference.
If I'm a Japanese user "Yes" is actually "そう", in French it's "Oui" etc. So it means if we're checking for the DisplayValue, none of those other languages have "Yes" as their Display Value, which will mean the Script will error and stop it's progress as the condition will never be met.
This is one of the reasons so many core tables in the platform have a "Value" column and a "Label" column. If for example we were referencing a choice in the [sys_choice] table and we had many languages at play (like this):
to save us having to make a messy piece of scripted logic per language, we can instead make a single tweak to our code:
var check = new GlideRecord('table');
check.addQuery('field', 'filter value');
check.query();
if(check.next()){
if(check.field.getValue('yes')){
return true;
}
} Note how we are now looking for the .getValue() and specifically for "yes" with a lowercase. This is because in our example (and yours will vary) has a server-side value of "yes". This then means that if there's a match (irrespective) of language, the system will always know what to do.
Whilst this code example is a massively oversimplified example, I hope it highlights the context of the Solution Design need. There shouldn't ever be a need to build any per language scripted logic in anything, providing you're aware of how your data model looks and what API's do what. Sometimes designing the data model is more important than writing a single line of code, because a data driven approach is always better.
Summary
To be honest, this is more of an issue where .getDisplayValue() is used in a conditional or IF statement, and there are many other scenarios with similar things to think about. However, the take away here is, when designing a solution for multi-lingual usage, you need to be mindful of inadvertently causing a dependency such as the above. Be rigorous with your naming standards and your coding standards and always look to check for the server-side values making your designs as data-driven as possible (e.g. look at how we do role inheritance with Groups as a prime example).
If you enjoyed this or found it useful, please like, share and subscribe for more as it always helps
