Overview
Large organisations typically have different needs in terms of languages depending on the type of persona consuming services provided in a shared platform like ServiceNow. Employees and contracts may need a list of languages, while customers or suppliers may need a different set of languages. ServiceNow does not offer an out of the box approach for this yet, but this article describes how you can minimise customisation to achieve such objective.
Strategy
The first thing we need to think about is, how can we specify in ServiceNow that a given UX (user experience) offers a set of languages, whereas another UX may need other languages. Not just that, but also, there are interfaces that are linked you need to bear in mind. For instance, say our fulfillers who work on the backend need the following languages:
- English
- Spanish
- French
However, say employees will be offered the same base languages plus these ones:
- Simplified Chinese
- German
- Italian
What would be the experience for an internal fulfiller (not outsourced) if they switched to the portal, realised they have those three extra languages and select one of them if they felt more comfortable with it? When switching back to the backend the instance should have everything translated into the three extra languages if we don’t want them to have a bad user experience with areas translated and areas that are not. This means, both user interfaces are linked. The languages we enable in the Employee Service Center (ESC) and backend must be the same. The same happens with the mobile applications for fulfillers and employees.
In the UML diagram above you can see how at the end of the day internal fulfillers can act as regular employees requesting anything in the ESC, such as Software, Hardware, Holidays, etc…
When defining actors of your instance, you need to remember some people may “change hats” throughout the day if you don’t want them to experience an unsatisfactory user experience.
If we also have customers, we can offer them a set of languages which may or may not overlap with the languages we offer our employees. The same happens with Suppliers. This is because they are not supposed to access the backend of ESC. If for some reason they are, be mindful of it.
Data Structure
First of all, we need to represent which UX has which language available. There is not perfect approach for this since there is not a UX table that gather all of them in a single place, but we could rely on the “sp_portal” table, since we say the backend and mobile apps are linked to the ESC in any case.
We should go do the “sys_m2m” table to create a many to many table that links both “sp_portal” and “sys_language”. To do so, you can type this on the filter and press enter:
Then click on “New” and create a many to many table like this:
With this table we are linking both portals and languages, so we can make several languages available for a given portal, and several portals could use the same language.
Then we need to show on the “Related lists” this new m2m table so it is shown this way on both Languages and Portals:
We can also take advantage of the situation to link some portals with some languages too like in the example:
Then we need to go to all places where languages can be changed and adapt the dropdowns so that only the languages we have selected here appear on the dropdowns. Bear in mind that out of the box all active languages will appear on these places.
The easiest dropdown to be changed is that on the “sys_user” table. We should create a Script include to query the m2m table and retrieve which languages are linked to which portals. Remember that the ESC portal defines not just the language for the ESC portal itself, but also for the Mobile applications for employees/internal fulfillers and backend.
Then you need to locate all the areas where you are displaying the available languages to be chosen from. Remember that OOTB, there are three places between the ESC and backend.
Adapting the portals
The ESC portal (i.e) has a widget under the profile picture that shows a dropdown to select the language.
This also happens in other portals. Adapt them all by calling the Script include mentioned before that queries the m2m table we created.
In the ESC, the “User Profile” widget has a “Language” dropdown we need to adapt.
Adapting the backend
This is a trickier situation, since we need to focus on two main areas.
On one hand, every “sys_user” record needs to offer the languages the specific user can utilise. If it’s a regular user then we need to show the languages linked to the ESC/Employee MobileApps/Backend, but if the user is a customer, supplier, etc… the languages may differ, it depends on the previously defined strategy.
On top of changing the “sys_user” language dropdown, users can always click on their icon located at the top-right corner, click on “Preferences” and then under “Language & Region” select one of the available languages. Bear in mind that ServiceNow will not differentiate OOTB, and will always display all available languages by default. Also, there is no way to adapt these languages as of today, so the main solution we have is adding a business rule/flow to revert the language to one of the available languages for the kind of user if the wrong one is selected.
Bear in mind with this solution all languages are displayed, causing users to believe they can freely choose from more languages they actually can. Additionally, they don’t have a way to know which languages they can choose from that list, so for them it’s a matter of trial and error. Unfortunately, ACLs and Query Business Rules don’t hide values in this dropdown, meaning the standard approach for hiding records doesn’t work in this scenario.
Adapting the Mobile Apps
Mobile Apps require manual intervention to display languages as here is no way to invoke the script include we created on this UX. The only thing we can do, for now, is showing a fixed list of languages, but we need to remember to expand it or reduce it when languages are added or removed respectively from the ones applicable to such UX.
Summarising
There is no OOTB approach for displaying different languages on different user experiences as of today, but this is a need in some multinational organisations that have a large variety of personas accessing their instances. To deal with this situation, we can implement the custom solution described above that lets us adapt options to the personas using each UX, and each UX has a different way to be adapted. It’s clear this solution isn’t perfect but it helps us achieve our objective in a quick and relatively easy to maintain way.
The recommendation while there is no OOTB way to achieve this, is not to accept this requirements unless its criticality is vital for the organisation.
Please like 👍 and share 🌍 this article to your colleagues if you found it useful.
