[BREAKING]: Changes to Phone Number Validation

Have more questions? Submit a request


  • Padraig McTiernan

    when this is done, and all numbers are thus in E164 format, our click-to-dial app will fail too. This is because a lot of PBXs do not accept E164 format readily. We will have to add further settings and code to revert the E164 to a dialable number for the PBX. And this code will have to take into account that numbers in Zendesk before this change are not E164. Thanks for the headaches.

  • Ilya Dovidovskii

    Thanks for such a short notice!

    Based on your example, say a customer currently has a non E164 phone number 5551234567, if the new code searches for phone number +15551234567, would the search results based on your search API return that customer's entry or not?

    Is the search API also going to be checking for E164 compliance when searching by phone?

  • Jitender Kumar

    This is good change.  Are there any changes for how search is performed on phone numbers? Currently we are trying to solve a problem where some numbers are stored with country code and some without.  Zendesk search API does an exact search for phone number, So we have to chop off country code to append a * so that it can match. 

  • Mayama

    So, does this mean phone number must be unique from now on? (unless the phone existed previous to this change).

    Maybe i could pass this when updating/creating the user:
      "shared_phone_number": "true"

    Will this work?

    Please confirm this, as it will be a huge problem for us as we work with people sharing dormitory phone numbers.


  • Douglas Galbi

    Will this phone number validation be automatically applied to phone-number fields in Zendesk-created ticket forms? If that's not going to happen from this announcement, is this change likely to be propogated to the web channel in the near future?

  • Jonathan March

    Requiring uniqueness would be a serious problem for us, for customers sharing a common switchboard or reception. Please allow this requirement to be disabled.

  • Daniel Pawluk

    Thanks for the feedback everyone,

    I'd like to first point out that nothing in this change requires a phone number to be unique. You can have non-unique numbers and the "shared_phone_number":"true" flag will automatically be enabled to show you the number is not unique. I have adjusted the post to more explicitly point this out. 

    As far as search goes, nothing will be changed in the way search looks for numbers. The method used by Jitender makes the most sense for looking up numbers that were entered before the change. 

    @Douglas this change will be reflected in both the API and the Agent Interface. In both cases we will return what was there and only require the validation for new numbers or numbers you are editing.

    Please don't hesitate to ask further questions and thanks again for the feedback!

    Daniel Pawluk

  • Neil Weldon

    Hi all, 


    We are moving towards being able to deliver multiple phone number support for users. This will allow you to store all of a users phone numbers against a profile. This is a much needed and sought after feature for quite a while now. As part of this work we are also looking to deal with a number of issues around what constitutes a phone number and how we use them as identities in Zendesk. Today we allow for anything to be stored in the phone number field, however we then require a formatting for them when they are direct line which is what turns them into a unique identity. We also have no simple way for phone numbers to be stored as direct line when being created via API.  What we are doing is delivering consistency for phone number formatting, following the E.164 standard that is well understood. Feedback we have received indicates a preferences for numbers to be automatically direct line which is why this is changing, however we are still allowing you to choose to change this behaviour if needed. We are also not forcing a change on currently stored phone numbers as we appreciate this would not be the best experience but when a number is edited (yes we will be supporting the editing of a number) or added we will be validating the format. 


    Uniqueness is not required but we will be limiting it to one non-unique number per user. We will support the updating/creating of a number with "shared_phone_number": "true" which will override the default of having the number as a direct line


    Searching behaviour will not be changing. You can currently search numbers in whatever format you want in whatever formats they are stored. We are able to provide suffix number matching. Users can search through local numbers even original numbers include which country and/or area codes.  Customers can continue using "phone:*2222" to get flexible phone number search support.


    We will not be making any changes that will be impacting ticket forms. 


    We have also had queries about making the numbers displayed being more human friendly (we will look into this) and if we will be able to support the storing of extensions (we will). 

  • David Rose

    I have several questions - this is talking about the API, but I'm assuming that the data field the API writes to is the same as the field that the human user interface writes to, so how will this restriction affect human users ?

    You have already mentioned displaying in a human friendly way e.g +44 207 183 0011 is great for a human, whereas +442071830011 is not, especially with repeating sequential digits.
    I'm guessing that most of your users are humans, so this is vitally important.
    Also you mentioned extensions - many places have voice menus "if you know your parties extension, enter it now", so would need to display the number as +44 207 183 0011 ext 322

    It seems one thing you won't support is parenthesised national numbers. In a large part of the world it is common to display a telephone number as 

    +44 (0) 207 183 0011

    where +44 is the country code and (0) is the trunk dialing prefix (https://en.wikipedia.org/wiki/Trunk_prefix) i.e if I'm calling from outside the UK I dial +44 207 183 0011 but if I'm calling from within the UK, I dial 0207 183 0011 - if numbers can't be stored in this way, then that will be the end of Zendesk for us - we call our customers - human to human, all the time.

    In my opinion storing the number in E164 format is changing things to the benefit of computers but not to the benefit of humans - at the very minimum it should be a configuration option - "store telephone numbers in E164 format/store numbers free form", but really isn't this just lazy programming - it's not difficult to take a human readable numbers and parse them into E164 format for those users that want this format ?

  • Theodore Chao

    Does this validation only apply to the default Phone field?  We use a custom text field for phone numbers and I am wondering if anything has to change on our end for this.



  • David McMullin

    This validation will only apply to the phone field. If you need the extra flexibility of an open text field, a custom field is a great alternative and this change will not affect you in any way.

  • Steven Yan

    Hi David, just wanted to let you know that the team is reviewing your questions and should be able to provide an update today. Thanks for your patience.

  • Wesley Gorman

    Hi David Rose,

    Thanks for the thoughtful feedback and comments.

    You made a very good point on formatting numbers in the Zendesk interface to make it more readable and accessible. The team responsible for this is working on formatting numbers for display, similar to the example you described, e.g. '+442071830011' -> '+44 207 183 0011'. This display enhancement may not be ready to go on August 8th but we'll aim to get it released pretty soon afterwards if it doesn't make the initial release.

    Additionally, we're actively working on support for extensions as part of this update to phone numbers. I expect this functionality to be ready for August 8th.

    In validating phone numbers, we settled on using the E.164 number formatting standard which is widely used and well supported. Unfortunately, having a '(0)' would be breaking away from that standard and for marginal additional readability. As mentioned in another comment below, if you need the flexibility to format and store numbers in this way then a custom text field may be the way to go.

  • Steven Yan

    Hi everyone, thanks for your comments about this change. After reviewing the feedback and doing further investigation into your use cases, we've decided to both delay any change with phone number validation as well as soften our approach so that this is not a breaking change.

    Please see our updated announcement for more information.

  • Alex Kaspian

    Hi, are these changes on production now, just curious because can't find it in settings ?

  • Daniel Pawluk


    The change for the setting mentioned in the latest article is live. This screenshot should help you find it. Thanks!

  • Alex Kaspian



  • Brian Vantassel

    If you have a number formatted like +1987654321 (Direct Line) and do a search by going to Advance, User  for *4321, the search will not find the user unless the number existed before the E.1645 Compliant Twillio massacre of my users phone numbers. 

    Having validation disabled does not prevent the phone numbers from being changed if you edit any user.

    So the fix made searching for a phone number not work.


  • Wesley Gorman

    Hi Brian,

    If you add a user property keyword in front of the number, e.g. phone:*4321, do you then find the user you were looking for? 

    According to the search FAQ, you can only use wildcard searches in combination with property keywords.

    Hope that helps.


Please sign in to leave a comment.

Powered by Zendesk