How to Validate a Phone Number in Power Automate
Phone numbers are useful in all kinds of automated marketing workflows. They make it possible, for example, to share SMS alerts and other updates with customers and/or clients directly.
Obviously, we don’t want any direct client or customer line of communication to be broken or unusable.
If phone numbers enter our Power Automate flows incorrectly, we should find out right away — and, thankfully, there’s an easy way to do that.
Validate Phone Numbers in Power Automate
Using the Cloudmersive Data Validation connector in Power Automate, we can check a phone number + country code combination to validate the entry fully. We’ll know, first and foremost, if the number we entered is valid given the input country code, but we’ll also get the number automatically restructured following E164, international, and national formatting conventions.
Take the below response, for example, which is returned after validating the US number 4152762094
:
{
"IsValid": true,
"Successful": true,
"PhoneNumberType": "FixedLineOrMobile",
"E164Format": "+14152762094",
"InternationalFormat": "+1 415-276-2094",
"NationalFormat": "(415) 276-2094",
"CountryCode": "US",
"CountryName": "United States"
}
In the above example, the “IsValid”: true
response tells us the phone number is a valid US line, and the E164, international, and national formatted numbers are included for our convenience directly below.
Walkthrough
We’ll now set up a quick example flow to show this API in action. We’ll use a manually triggered instant cloud flow in this context to set up a quick and easy test case.
We’ll want to test out a few different phone number entries in this flow, so we’ll begin by opening our Manually trigger a flow action and creating a string input.
Next, we’ll add a new action in our flow and search for Cloudmersive connectors in the Power Automate connector library.
We’re looking for the Cloudmersive Data Validation connector, which has a blue-gray logo.
We’ll click “See more” to view the actions list, and from there, we’ll locate the Validate phone number (basic) action at the bottom of the list. Note that it’s labeled as “(basic)” in the API spec because there’s a more advanced version of this API available in the enterprise Validation API SDK.
After we select this action, we’ll need to create our Data Validation connection with a Cloudmersive API key. We can get a free API key by creating a free account on the Cloudmersive website; that’ll allow us a limit of 800 API calls per month with zero additional commitments across ALL Cloudmersive connectors.
Once we’re looking at the Validate phone number action, we’ll click “Show all” to view the request parameters.
Here, we’ll notice the option to set country code and phone number parameter values. The Value/DefaultCountryCode parameter selects “US” if no other value is specified, so I’ll be leaving that blank in my example flow.
In the Value/PhoneNumber parameter, we’ll enter the manual trigger string input we created in our initial step.
Now we’ll save our flow and run a few manual tests.
We’ll start by entering a normal phone number string with dashes between each segment.
The formatting we used here in this example is valid, and it’s pretty close to being a full internationally formatted string. It’s just missing the +1 for US numbers, which the API response added in the “InternationalFormat” value.
We’ll now test again — this time entering the same phone number string with no dashes or spaces.
Once again, we’ll receive an “IsValid”: true
response, and once again we’ll notice the API returned three formatting options for our input.
In our third test, we’ll enter the same string as before — only this time, we’ll delete the final number in our phone number string.
This time, we’ll notice we got an “IsValid”: false
response. We also got an “Unknown”
response in the “PhoneNumberType”
value, where we’d consistently received “FixedLineOrMobile”
in previous responses. The API still attempted to reformat the number following E164, international, and national formatting conventions, but it was unable to complete those values without the missing digit.
Conclusion
We can use the “IsValid”
response to pivot our flows when phone numbers are entered incorrectly, and we can conditionally leverage the various phone number formatting strings only when entries are deemed valid.
This can immediately enhance our client/customer communication workflows, ensuring poor data entry is flagged and correct data entry is logged to our database following one (or multiple) formatting convention.