Need to override Workday integration for international phone number

[Duodecimal]

The Geneva updates for Workday include some bidirectional HR data integration. We have a custom integration handling this for now, and I'll need to add a wrapper for workday_data_loader to override the getPhonecomponents() method.

The issue is that international phone numbers are not well supported by the existing code -- I tested it when we ran into a problem with UK (+44) phone numbers, and the Geneva code worked for that, resolving that specific issue. However, phone numbers for India and Brazil immediately broke.

The relevant code:

var format = (phoneNumber.split(/[ ]+/));
var formattedNumber = [];
for (var i=0;i<format.length;i++) {
     var part = (format[i]);
     if (part.indexOf('+')==0)
           formattedNumber['intl_code'] = part.replace('+','');
           else if (part.indexOf('(')==0)
           formattedNumber['area_code'] = part.replace(/[()]/g, '');
           else
           formattedNumber['phone_number'] = part.replace(/[-]/g, '');
     }

Indentation and other style irregularities preserved from the original, despite it making my eyes twitch and fingers itch. Yes, that last brace closes the for loop. Yes, a variable is instantiated as an array but then assigned properties like an object. Yes, bracket notation is used instead of dot notation. Not sure why the regular expressions are written that particular way, either. The irregularities are at least consistent throughout the code.

The functional issue here is that it was more luck than design that UK phone numbers worked -- the trunk dialing digit was enclosed in parentheses, and was not separated by a space from the region code. So the second element of the array was "(0)20"; since that had a paren in it, it was set to formattedNumber.area_code as "020". Which Workday happily accepts.

Unfortunately, the e164 format for other countries does not set the region coding off with parenthesis. It's usually the first group of numbers after the country code, but not always -- some phone numbers don't have a region code at all. Workday rejects these phone numbers as having too many digits in the actual phone number part; moving the region or city code to the area code part does work, however. Workday also unfortunately accepts phone number parts with no area code, so we were originally sending the London office phone numbers without the "020"; since I didn't get an error message, I assumed incorrectly that Workday knew the correct region code based on the user's location, and supplied it itself. Someone who had access to the system let me know that this wasn't the case, five months after go-live.

Anyway.   I had to write some unfortunate-looking code to get full international phone numbers into Workday via the webservice. The value in sys_user.phone in our instance is already formatted correctly via the GlideElementPhoneNumber object (not sure if that's documented much at all yet?). Here's what we're using for now:

// phoneDigits is basically sys_user.phone.replace(/\D/, "")
// so a US number would look like: +1 (212) 555-1234, making phoneDigits 12125551234
var formattedNumber = {};
var gePN = new GlideElementPhoneNumber();
// if we have a valid number, parse it
if (gePN.setPhoneNumber("+" + phoneDigits, false)) { 
     var phoneDisplay = gePN.getGlobalDisplayValue() + "";
     // Split the formatted number by spaces or dashes
     var phoneArr = phoneDisplay.split(/[\s\-]+/);
     for (var i = phoneArr.length; i >= 0; i--) { 
           var part = phoneArr[i] + "";
           if (part.indexOf("+") == 0) { 
                 intl_code = part.replace(/\D/g, "");
                 continue;
           }
           if (part.indexOf("(") == 0) { 
                 area_code = part.replace(/\D/g, "");
                 continue;
           }
           if ((phone_nbr.length + part.length <= 😎 || (!phone_nbr && part.length >= 8)) {
                 phone_number = part.replace(/\D/g, "") + phone_nbr;
                 continue;
           }
           if (part.length <= 3 && !area_code && i == 1) { 
                 area_code = part.replace(/\D/g, "");
                 continue;
           } 
           // your error generator goes here - phone number part was not parseable
     }
}

This is temporary code. Some of the stupidity is leftover from earlier versions of the custom code, such as for some reason stepping backwards through the array? I can't explain all my decisions. The above will be our starting point for when we get to rewriting it in an override wrapper for workday_data_loader.

The point is, this code is working for us, for now; we have users in Brazil, Singapore, Tokyo, London, Melbourne, Frankfurt, Mumbai, Paris, Madrid, and the US; so far Workday isn't throwing a fit over the way we're sending the phone numbers anymore.

[vmedikon]

Thank you Anthony for the above information. We are aware of issues with E.164 formatting on servicenow platform, which has been addressed in Helsinki. Hopefully, integration behaves in a much more predictable fashion on Helsinki as compared to Geneva.