Power Automate: isFloat function

Validating user input is one of those things we tend to skip until a Flow blows up in production because someone typed "1,5" instead of "1.5". The Power Automate "isFloat" function helps us catch these issues before they cascade into broken expressions and confused users. It checks whether a string can be interpreted as a floating-point number and returns a simple true or false, which makes it perfect for guarding conversions or branching logic.

Let's look at how it works.

Usage

The "isFloat" function follows this pattern:

isFloat('<string>', '<locale>'?)

Where:

• <string> (required) is the text you want to evaluate.
• <locale> (optional) is an RFC 4646 locale code, like 'en-US', 'de-DE', or 'fr-FR'. When you don't provide it, the function uses the invariant culture, which means the period is the decimal separator and the comma is the thousands separator (which is super strange here in Europe for example).

Let's start with the simplest case:

isFloat('10.5')

will return

true

That's what we expect. A standard decimal number is a valid float. Now let's try with an integer:

isFloat('10')

will return

true

Wait, an integer? Yes. Integers can always be represented as floating-point numbers, so the function returns true. If you want to distinguish between the two, you'll need to pair this with the "isInt" function or do a separate check.

Let's try with thousands separators:

isFloat('10,000.00')

will return

true

The invariant culture handles the comma as a thousands separator without issue. But what happens if we feed it a string in a different locale format?

isFloat('10.000,00')

will return

false

This one trips up many people. The string is a perfectly valid number in Germany, but the invariant culture sees the comma in the wrong place and rejects it. That's where the locale parameter comes in:

isFloat('10.000,00', 'de-DE')

will return

true

The locale is incredibly important because the same expression but changing that to portugal for example will return false instead of true.

isFloat('10.000,00', 'pt-PT')

will return

false

Finally, let's see what happens when the string is not numeric at all:

isFloat('hello')

will return

false

As expected. The function returns false for any string that cannot be parsed as a number under the chosen locale.

Edge Cases

Integers always return true

As shown above, isFloat('10') returns true. This catches people off guard because they expect "isFloat" to mean "has a decimal point". It doesn't. It means "can be parsed as a floating-point number", and integers qualify. If you need to reject integers, validate with both functions:

and(isFloat(variables('USER_INPUT')), not(isInt(variables('USER_INPUT'))))

• isFloat(...) confirms the string is numeric.
• not(isInt(...)) rejects values that are also valid integers.
• and(...) ensures both checks pass.

The function only accepts strings

If you pass a number directly, the Flow will throw an error rather than return false. For example, this fails:

isFloat(triggerBody()?['someNumberField'])

When the field is already a numeric type, you'll see something like:

Flow run failed. Action 'Compose' failed: Unable to process template language expressions in action 'Compose' inputs at line '0' and column '0': 'The template language function 'isFloat' expects its first parameter 'string' to be a string. The provided value is of type 'Integer'. Please see https://aka.ms/logicexpressions#substring for usage details.'.

This is expected since if the value is already an integer or a float there's no need for the function at all, but if you need it neverthelss the fix is to wrap the value with the "string" function first:

isFloat(string(triggerBody()?['someNumberField']))

• triggerBody()?['someNumberField'] safely grabs the field from the trigger.
• string(...) converts it to a string so "isFloat" can evaluate it.

Locale mismatches return false silently

If you don't provide the right locale, the function won't crash. It will simply return false, which can hide bugs because the Flow keeps running but takes the wrong branch. Always think about where the data is coming from. A user typing in a German browser will produce different strings than a CSV exported from an English-speaking system.

Null and empty strings

Passing a literal null raises an error because the function expects a string.

Flow run failed. Action 'Compose' failed: Unable to process template language expressions in action 'Compose' inputs at line '0' and column '0': 'The template language function 'isFloat' expects its first parameter 'string' to be a string. The provided value is of type 'Null'. Please see https://aka.ms/logicexpressions#substring for usage details.'.

An empty string '' returns false. If your data might be null, sanitize it first with the "coalesce" function:

isFloat(coalesce(variables('USER_INPUT'), ''))

• coalesce(..., '') replaces null with an empty string.
• isFloat(...) then evaluates the safe value and returns false instead of failing.

Limitations

No conversion, only validation

The "isFloat" function only checks. It does not convert the value for you. Once you confirm the string is valid, you still need to call the "float" function to use it as a number.

Expression size limit

As with all Power Automate expressions, you're capped at 8,192 characters. Nesting "isFloat" inside complex validations rarely hits this ceiling on its own, but if you find yourself building a long combined expression, consider breaking it into multiple variables for clarity.

Locale dependency on the runtime

The function uses the locale you pass, not the locale of the user or the Flow's region. There is no way to ask "what locale is my data in?". You must know it ahead of time or test for multiple locales explicitly.

Recommendations

Here are some things to keep in mind.

Always sanitize before validating

Wrap your input with the "coalesce" function to guard against nulls, and convert non-strings with the "string" function so the function never crashes on unexpected input. A defensive pattern looks like this:

isFloat(coalesce(string(<insertValue>), ''))

This way, your validation only ever returns true or false, never an error.

Pair with isInt for strict checks

If you specifically need a decimal number and want to reject whole numbers, combine "isFloat" with the "isInt" function. It's the cleanest way to express "this must be a decimal, not an integer".

Be explicit about the locale

Even when the invariant culture works for your data today, write the locale parameter anyway. It documents your intent and protects you when someone downstream changes the data source or pastes in a value from a different system.

Validate before converting

Always run "isFloat" before calling the "float" function. Without the check, an invalid string will throw a runtime error and stop the Flow. With the check, you can route invalid values to a "send a notification" branch or a default value instead.

Don't nest it

There is no scenario where nesting "isFloat" inside another "isFloat" makes sense. It will return an error since "isFloat" will require always a string and not a boolean. If you see this in your Flow, you've likely got a logic bug to fix.

Final Thoughts

The "isFloat" function is a small but powerful guard against bad data. Use it whenever a user, an external system, or a SharePoint text column hands you something that should be a number, and let it tell you "yes" or "no" before you try to do math with it. Combined with the right locale and a little defensive wrapping, it will save you hours of debugging weird conversion errors.

Sources

Microsoft's "isFloat" Function Reference

Back to the Power Automate Function Reference.

Photo by Markus Krisetya on Unsplash