phone numbers stored incorrectly since latest update (country prefix)

%3CLINGO-SUB%20id%3D%22lingo-sub-401356%22%20slang%3D%22en-US%22%3Ephone%20numbers%20stored%20incorrectly%20since%20latest%20update%20(country%20prefix)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-401356%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20been%20using%20Microsoft%20bookings%20quite%20a%20bit%20and%20really%20like%20it%20more%20and%20more.%3C%2FP%3E%3CP%3ERecently%20there%20was%20an%20update%20that%20changed%20how%20phone%20numbers%20are%20entered%20%26amp%3B%20stored%20in%20the%20related%20contact%20which%20now%20affects%20our%20text%20message%20reminder%20system.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENot%20sure%20when%20the%20last%20update%20reached%20us%20but%20it%20brought%20with%20it%20two%20major%20problems%20related%20to%20how%20phone%20numbers%20are%20handled%20now.%3C%2FP%3E%3COL%3E%3CLI%3Ethe%20new%20%22phone%20number%20prefix%22%20field%20ALWAYS%20defaults%20to%20%22United%20states%20(%2B1)%22.%20There%20is%20no%20way%20(at%20least%20that%20I%20could%20find)%20to%20change%20the%20default%20country%20meaning%20(since%20our%20business%20is%20operating%20out%20of%20Austria)%20clients%20always%20have%20to%20open%20the%20drop%20down%20box%20and%20select%20the%20correct%20country%20first.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FLI%3E%3CLI%3EThe%20number%20itself%20is%20unfortunately%20%22partly%22%20butchered%20when%20saved%20which%20is%20a%20real%20problem%20for%20our%20SMS%20reminder%20system.%20The%20%22%2B%22%20in%20the%20prefix%20is%20for%20some%20reason%20ignored%20completely.%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3EExample%3A%3C%2FSTRONG%3E%20a%20new%20client%20makes%20a%20booking%20and%20enters%20the%20phone%20number%3A%26nbsp%3B%20%22United%20States%20%2B1%20%2F%2023456789%22%3CBR%20%2F%3EThis%20number%20is%20then%20stored%20as%20%22123456789%22%20instead%20of%20either%20%22%3CSTRONG%3E%2B123456789%3C%2FSTRONG%3E%22%20or%20%22%3CSTRONG%3E00123456789%3C%2FSTRONG%3E%22%20resulting%20in%20a%20%3CSTRONG%3Ewrong%20number%3C%2FSTRONG%3E.%3CBR%20%2F%3EWe%20have%20a%20cloud%20based%20appointment%20reminder%20system%20that%20automatically%20sends%20out%20text%20messages%20after%20a%20booking%20to%20a%20clients%20phone%20number%20by%20searching%20for%20a%20valid%20number%20within%20each%20new%20appointment.%20However%2C%20because%20the%20leading%20zeros%20or%20the%20%22%2B%22%20is%20now%20ignored%20and%20not%20passed%20on%20by%20Microsoft%20Bookings%2C%20all%20the%20phone%20numbers%20are%20therefore%20invalid%20and%20text%20messages%20are%20only%20send%20out%20after%20we%20manually%20open%20each%20appointment%20in%20the%20calendar%20and%20add%20either%20a%20%22%2B%22%26nbsp%3B%20or%20a%20%2200%22%20in%20front%20of%20the%20number.%3CBR%20%2F%3E%3CBR%20%2F%3EFurthermore%20if%20a%20client%20makes%20a%20mistake%20and%20adds%20a%20leading%20zero%20into%20the%20number%20field%2C%20bookings%20(instead%20of%20intelligently%20ignoring%20it)%20parses%20this%20on%20as%20well%20resulting%20again%20in%20an%20invalid%20number.%3CBR%20%2F%3E%3CBR%20%2F%3E%3CSTRONG%3EExample%3C%2FSTRONG%3E%3A%20A%20client%20enters%20%22United%20States%20%2B1%22%20023456789%3CBR%20%2F%3EThe%20resulting%20number%20should%20be%20%22%3CSTRONG%3E%2B123456789%3C%2FSTRONG%3E%22%20or%20%22%3CSTRONG%3E00123456789%3C%2FSTRONG%3E%22%20but%20is%20actually%20stored%20as%20%221023456789%22%3CBR%20%2F%3E%3CBR%20%2F%3EThis%20is%20quite%20a%20big%20problem%20for%20us%20at%20the%20moment%20so%20a%20fix%20(or%20even%20a%20temporary%20workaround%20until%20a%20fix%20can%20be%20rolled%20out)%20would%20be%20greatly%20appreciated!%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-401356%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Ebookings%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
New Contributor

We have been using Microsoft bookings quite a bit and really like it more and more.

Recently there was an update that changed how phone numbers are entered & stored in the related contact which now affects our text message reminder system.

 

Not sure when the last update reached us but it brought with it two major problems related to how phone numbers are handled now.

  1. the new "phone number prefix" field ALWAYS defaults to "United states (+1)". There is no way (at least that I could find) to change the default country meaning (since our business is operating out of Austria) clients always have to open the drop down box and select the correct country first. 

  2. The number itself is unfortunately "partly" butchered when saved which is a real problem for our SMS reminder system. The "+" in the prefix is for some reason ignored completely.

 

Example: a new client makes a booking and enters the phone number:  "United States +1 / 23456789"
This number is then stored as "123456789" instead of either "+123456789" or "00123456789" resulting in a wrong number.
We have a cloud based appointment reminder system that automatically sends out text messages after a booking to a clients phone number by searching for a valid number within each new appointment. However, because the leading zeros or the "+" is now ignored and not passed on by Microsoft Bookings, all the phone numbers are therefore invalid and text messages are only send out after we manually open each appointment in the calendar and add either a "+"  or a "00" in front of the number.

Furthermore if a client makes a mistake and adds a leading zero into the number field, bookings (instead of intelligently ignoring it) parses this on as well resulting again in an invalid number.

Example: A client enters "United States +1" 023456789
The resulting number should be "+123456789" or "00123456789" but is actually stored as "1023456789"

This is quite a big problem for us at the moment so a fix (or even a temporary workaround until a fix can be rolled out) would be greatly appreciated!

0 Replies