I'm attempting to leverage the .dialingCode property and finding that it isn't being set as described in https://help.mypurecloud.com/articles/about-the-phone-number-data-type/. Based on the documentation, I'm expecting ToPhoneNumber().dialingcode to return "1" but my results are as follows (obfuscating the actual number):

Prior to these debug expressions, Task.CallANI is set to Call.Ani...

ToAudioTTS(ToPhoneNumber(Task.CallANI).dialingCode, Format.String.playChars) -> plays nothing

ToAudioTTS(ToString(ToPhoneNumber(Task.CallANI).isGlobal)) -> plays "true"

ToAudioTTS(ToPhoneNumber(Task.CallANI).e164, Format.String.playChars) -> plays "+ 1 8 4 7 5 5 5 2 8 9 3"

ToAudioTTS(ToPhoneNumber(ToPhoneNumber(Task.CallANI).e164).dialingCode, Format.String.playChars) -> plays nothing

ToAudioTTS(ToString(IsNotSetOrEmpty(ToPhoneNumber(Task.CallANI)))) -> plays "false"

ToAudioTTS(ToString(ToPhoneNumber(Task.CallANI).dialingCode == " ")) -> plays "false"

ToAudioTTS(ToString(Length(ToPhoneNumber(Task.CallANI).dialingCode))) -> plays nothing

ToAudioTTS(ToString(IsSet(ToPhoneNumber(Task.CallANI).dialingCode))) -> plays "true"

ToAudioTTS(ToString(ToPhoneNumber(Task.CallANI).dialingCode == "")) -> plays "false"

So, the number is being recognized as a global E.164 number, .dialingCode is being set, but it is empty. According to the documentation, this is not a valid value and it should be "1."

Any suggestions on how to get the country code (dialingCode)?

@James Ullyot? ?

Thanks @George Ganahl? 

Hi Patrick!

First of all, thank you very much for the amount of detail you provided in your posting above. It was very specific and helpful for us.

We've done some investigation in to what you reported above and have created a development issue to address what you're seeing. From our initial investigation it looks like there is an internal data type inconsistency with the dialingCode property value that's set on the returned phone number instance from the ToPhoneNumber function invocation. :(

As a workaround, and this should definitely not be needed under normal circumstances, the addition of the following ToString / ToInt conversion calls around the dialingCode property access should fix things up to get the dialing code returned as a string as expected:

```

ToString(ToInt(ToPhoneNumber(Task.CallANI).dialingCode))

```

Then looking at your sample code above with the Task.CallANI variable you could do this:

```

ToAudioTTS(ToString(ToInt(ToPhoneNumber(Task.CallANI).dialingCode)), Format.String.playChars)

```

Thank you very much for bringing this to our attention!

Jim

Changing decisions tests to integers works too and eliminates one iteration of casting/conversion (country codes should be unique regardless of format).

Will this continue to function properly when the internal coding error is resolved? That is, will ToInt() cause the callflow to fail if this expression is encountered:

ToInt(ToPhoneNumber(Task.CallANI).dialingCode)

when ToPhoneNumber(Task.CallANI).dialingCode returns NOT_SET?

Hi Patrick!

Thanks for the follow up. :)

If you look at the ToInt function expression help inside of the Architect UI, there is an implementation that accepts a string parameter and if the submitted String value is a NOT_SET String, the ToInt function call will return a NOT_SET Integer. Therefore, the expression you have above will continue to be valid.

With regards to the dialing codes themselves, as you can see the dialingCode property on the phone number data type is a String. Similarly, there is read only System.Regions built-in variable available in call flows as well and if you were to use the following reference in an expression:

System.Regions.US.dialingCode

That will resolve to the String value "1" at runtime and not the Integer value 1. Currently with the workaround I originally posed, you could see if the dialing code for a phone number value is for the United States like this:

System.Regions.US.dialingCode == ToString(ToInt(ToPhoneNumber(Task.CallANI).dialingCode))

and eventually once the dialingCode fix is in place switch that to this:

System.Regions.US.dialingCode == ToPhoneNumber(Task.CallANI).dialingCode

If you want to cast the dialing code to an Integer, you can but if you also want to use the built in System.Regions variable like I showed above then you'd also need to perform a ToInt call:

ToInt(System.Regions.US.dialingCode) == ToInt(ToPhoneNumber(Task.CallANI).dialingCode)

And sure, if you want to use a hard coded value of 1 for the dialing code as an Integer this would work:

1 == ToInt(ToPhoneNumber(Task.CallANI).dialingCode)

I wanted to make sure I pointed out that natively Architect is dealing with dialing codes as String values and the System.Regions variable can improve expression readability. Internally the Architect parser resolves System.Regions.US.dialing to "1" at design time so there's no runtime penalty to use it over hard coding a String or Integer literal value for the dialing code.

One final note: Once we get the fix in place so that the dialingCode set on the returned phone number value from the ToPhoneNumber function call is a String, it will require that you republish the call flow to pick up that fix.

Thanks!

Jim

Right now I have a switch node with the following cases:

• ToInt(ToPhoneNumber(Task.CallANI).dialingCode) == 1
• (IsSet(ToPhoneNumber(Task.CallANI).dialingCode)) and (ToInt(ToPhoneNumber(Task.CallANI).dialingCode) != 1)
• Default

I run the same tests using 61 in our APAC instance.

Since ToInt() is recovering the integer value erroneously in .dialingCode now, and should also convert a string value to integer, it sounds like this code will survive the publishing of new code by Genesys. Can you confirm this or will all my call flows break when you push new code?

Yes, those expressions should work after the production service is updated with the fix and the call flow is republished. :)

Jim

Hi Patrick,

I wanted to follow up on this and let you know that we have deployed the fix to production so the dialingCode property exposed off the phone number value returned from a ToPhoneNumber function call has been corrected to return a String. The workaround conversion functions that I mentioned in earlier posts should no longer be needed. Please remember that to take advantage of this fix you'll need to republish your call flow.

Thanks!

Jim