Open Aycorn opened 1 year ago
@Aycorn ask Andy to provide a function to translate phone number. this is part of Automation's responsibility. The format is correct and we should not alter the format from server.
If I change a way of saying, the server should always provide E164 phone format. You can search for that spec.
What Andy can provide is an help connector to translate phone number into national or international format. So his connector can check and have following condition.
We use Google's library to translate and Google's phone library has been ported to C# and JavaScript I believe. So the connector can be created by either library.
Additionally, form field can be multi entry. So phone number can have multiple values.. Depends on how Andy's form result v2 formats, he also need to put that into consideration when convert from E164 to national format.
e.g. if he join all the options by ;
, then split before parse.
Hi @Nness Thanks for reply. Aaron opened this on my behalf. I'm not looking to change any formatting that is already supplied, I am only looking to have the formatted value passed to Power Automate's 'Get a Form Result' function, instead of it passing the unformatted number.
When the data is passed to Power Automate, the number is formatted as the user entered it, adding the +61
What would be much more useful is if the formatted version was passed, so that 'Get a form result' provided +61 400 000 000
A similar issue was addressed in a 'Get a form result v2' action concerning the dynamic field, where v1 was receiving 'No results for
I hope this makes sense.
Thanks,
Rob.
That is exactly what I am talking about. @Rob-cv . Server will never provide formatted data but proper E164 format. Then it is UI and receiver's job to format it. Where our connector could have help method to format it.
By enforce server only provide E164 format, then receiver or UI can decide what to do if that make sense. I am asking the person who is working on our Power Automate to add additional helper action to format the data.
Additionally, even though E164 format is not as reader friendly as national format, but it is accepted by all devices and all software. It include country code, region code. And it is preferred format for phone number link in HTML. It can also include extension within.
When asking users to enter values, especially with phone numbers, there is often significant validation required to ensure it is formatted correctly. When companies want to ensure a specific format is used as part of their branding, building our own validation based on the amount of possibilities a user may enter is very difficult.
The validation that is built into the current phone field in DeskDirector takes this need for validation away from us, by advising the user the number is invalid, or formatting the number in a consistent, known format, that is much easier to use in automation tasks.
The issue is that when the number is delivered to our automation platform, in this case Power Automate, the formatted number is not passed through in the form result, which means we cannot take advantage of the automatic formatting that DeskDirector applies.
For example:
Text entered on the form: +610399999999 Form reformatted: +61 3 9999 9999 Power Automate ‘Get a form result’ value: +61399999999 Power Automate ‘When a ticket is created or updated’ ‘note/content’ value: \r\n\r\n### Enter the direct phone number\r\n+61 (03) 9999 9999 \r\n\r\n
As a workaround for this current issue, the ‘note/content’ value is the closest format to the DeskDirector value (although is still different), so I scrape the text out of the ‘note/content’ value using a sequence of string search functions in Power Automate and removing the parenthesis.
If the formatted number were provided in the ‘Get a form result’ output, I would not need to search the ‘note/content’ value for the number (and the search text needs to be changed every time I update the question text), and more importantly, the format of the number is guaranteed, making it easier for anyone to reformat it as required in their automation processes.