New Business Rule on User Table in Yokohama Patch 5

[Tim Deniston]

A new business rule was inserted on the sys_user table with Yokohama Patch 5. The BR is called "Prevent invalid country code" and has a sys_id of 3b638e8338596210f8773223ad5a62dd. This is causing an issue with updating users all of a sudden. If a user has an invalid Country value, all of a sudden no updates can occur on the user until this is corrected. This may be a problem for anyone who has LDAP or Azure AD pushing Country values that don't exactly conform to what ServiceNow is expecting. The Country field has historically been a string field with choices that have inconsistent values (US and USA and United States, for example). Starting with Yokohama Patch 5, these apparently need to all be corrected. 

The Yokohama Patch 5 release notes do not mention this new BR but it's sure having a big impact. 

[Dave Becker]

Xanadu Patch 9 we started noticing this. We have a case open to review exactly this "Prevent invalid country code" business rule. 

[Tim Deniston]

Now Support indicated that PRB1841312 is the reason for introducing the new business rule. (I can't see that PRB record, so that's not helpful.)

They apparently added some server-side validation of preferred_language and country to address a security vulnerability.

The recommendation from them is...

"- Fix the related country codes to be valid
- OR modify the BR to accept the custom codes (use a whitelist mechanism, this should be safe)"

Until I can put one of those recommendations in place, I am disabling the business rule.

[Gonzalo_S]

We started having issues as well just straight after Xanadu Patch 9 was introduced, and it was causing caos as external user registrations weren't being processed because we had the "Country" variable as a string (as it was before).

[FilipVacula]

For future reference, it seems it was introduced in Yokohama Patch 4a. Instances from the same group on Patch 4 do not have this Business Rule, while instances on Patch 4a do.

I agree that this is a breaking change which should have been announced at least a few months before deployment and not rolled out practically silently.

I also found a related Knowledge Article KB2310555.