How to Convert Float to Integer in Power Automate [3 Methods]

I ran into this problem the first time I built an inventory flow for a client who ran a small distribution business. Their Excel Online (Business) table stored every quantity as a decimal, even whole units like 24 came through as 24.0, because Excel treats every number as a floating-point value internally.

The client’s SharePoint inventory list had a Number column locked to zero decimal places, and the flow kept throwing validation errors every time it tried to write 24.0 into a field that expected a clean whole number.

That’s when I learned there’s no single built-in “convert float to integer” action in Power Automate. You have to build the conversion yourself using an expression, and depending on your business rule, you’ll want a different expression each time. Sometimes you need to drop the decimal completely, sometimes you need proper rounding, and sometimes you need to always round up no matter what.

By the end of this guide, you’ll know exactly which expression to use for each of those situations, plus how to plug the result straight into a real flow that updates a SharePoint list.

Why You Need to Convert Float to Integer in Power Automate

A float (short for floating-point number) is any number that can carry decimal places, like 24.75 or 1500.0. An integer is a whole number with no decimal component, like 24 or 1500. Power Automate doesn’t always care about the difference internally, but the systems you connect to almost always do.

Here’s where this bites people in real flows:

• Excel Online (Business) returns every numeric column as a float, even if every cell only ever contains whole numbers.
• A SharePoint list Number column set to “0 decimal places” will reject or silently reformat a float value coming from a Compose action.
• APIs for ERP systems, accounting tools, and custom line-of-business apps frequently expect a strict integer data type in the request body, and will throw a schema validation error if you send 24.0 instead of 24.
• Dataverse whole number columns behave the same way; passing a float into them causes the flow run to fail with a type mismatch error.

This is why converting float to integer in Power Automate is such a common need, even though it looks like a trivial data type question on the surface.

Get the wrong expression, and you’ll either lose precision you actually needed, or you’ll round in a direction that breaks a business rule (like under-billing a client because you rounded down instead of up).

It’s the same family of data type headache you run into when you convert a string to a decimal number in Power Automate or work with any of Power Automate’s string functions — the value looks right on screen, but the underlying data type doesn’t match what the destination expects.

I’ll use one consistent example throughout this article: a Product Inventory flow for a mid-sized distributor. The SharePoint list is called Products, with columns ProductName (the default Title column), ProductQuantity (Number column, float values coming from an Excel import), and ProductPrice (Number column, also float). Our job is to clean up ProductQuantity so it lands in the list as a whole number every time.

Convert Float to Integer in Power Automate

Now I will tell you different ways to convert a float to an integer in Power Automate.

Method 1: Truncate the Decimal With the int() Function in Power Automate

This is the fastest fix, and it’s the one I reach for first when the business rule is simply “drop whatever is after the decimal point; we don’t need it.” Power Automate’s int() function converts a string into an integer, but here’s the catch nobody tells you upfront: int() expects a string that already looks like a whole number. Feed it a float like 24.75 directly, and you’ll hit a template expression error because 24.75 isn’t a valid integer string.

The workaround is to split the number on the decimal point first, grab the part before the dot, then run that through int(). Here’s the expression I use inside a Compose action:

int(first(split(string(triggerBody()?['ProductQuantity']),'.')))

Let’s break that down in plain language:

1. string(triggerBody()?[‘ProductQuantity’]) converts the float value into text, so 24.75 becomes “24.75”.
2. split(…,’.’) breaks that text into an array using the decimal point as the separator: [“24”, “75”].
3. first(…) grabs the first item in that array, which is “24”.
4. int(…) converts that clean whole-number string into an actual integer value.

If you’re testing this on its own before wiring it into a real flow, use an instant cloud flow with a manual trigger and a Number input set to a float like 16.233. Drop the expression above into a Compose action, referencing the manual trigger’s number output instead of triggerBody()?[‘ProductQuantity’]. Run the flow, and the Compose output will show 16, not 16.233 and not 17. That’s truncation, not rounding, and it’s a distinction that matters a lot depending on your use case. This is the same core technique behind converting a string to an integer elsewhere in your flows, so once you understand it here, you can reuse it anywhere you convert a string to an integer in Power Automate.

Pro tip: I’ve been burned by assuming int() rounds. It doesn’t. If a client’s Product Price came through as 1495.99, this method returns 1495, not 1496. If your business logic needs anything close to “nearest whole number,” skip straight to Method 2.

Method 2: Round to the Nearest Whole Number With formatNumber

Truncation works fine for inventory counts, but it’s the wrong call for anything involving money or performance scoring, where rounding to the nearest whole number is the expected behavior. This is where the formatNumber function earns its place in your flow.

formatNumber takes a number and a format string, then returns a formatted string. Passing the format code 'F0' tells it to return a fixed-point number with zero decimal places, and it rounds to get there instead of chopping off digits. Since formatNumber always returns a string (even though it looks numeric), you still need to wrap it in int() to get an actual integer value your flow can use in calculations or write into a number field:

int(formatNumber(triggerBody()?['ProductQuantity'],'F0'))

Walking through this: if ProductQuantity comes in as 24.6, formatNumber rounds it to “25” as a string, and int() converts that string into the integer 25. If it’s 24.4, you’ll get 24. This matches how most people intuitively expect “round to nearest whole number” to behave.

I use this exact pattern anywhere a client wants an average, a score, or a calculated metric displayed as a clean whole number without losing accuracy in the process. It’s also the safer default when you’re not sure which rounding behavior a stakeholder actually wants; rounding to the nearest is usually the least surprising choice.

If you also need to check whether an incoming value is a whole number before deciding which method to apply, pair this with the isInt function inside a Condition so you only run the conversion logic when it’s actually needed.

In my experience, this is the method most people should be using by default, and Method 1 should be the exception you reach for only when you specifically need truncation. I’ve seen more than one flow quietly under-report totals for months because someone used int() on a raw float instead of pairing it with formatNumber.

Method 3: Force Rounding Up or Down for Business Rules in Power Automate

Sometimes neither truncation nor standard rounding is correct, because the business rule itself demands a specific direction.

Think about a licensing flow that charges per whole seat: if a usage report shows 4.2 seats used, you can’t round down to 4 (you’d under-license the account) and you can’t round to nearest either (4.2 rounds to 4, same problem).

You need to always round up, which is called a ceiling operation. Power Automate has no built-in ceiling() or floor() function, so you build the logic yourself with a Condition action.

Here’s the setup I use for a “round up if there’s any decimal at all” rule, built the same way you’d set up any multi-branch logic with an If function in Power Automate:

1. Add a Compose action to get the truncated whole number, using the same expression from Method 1:

int(first(split(string(triggerBody()?['ProductQuantity']),'.')))

2. Add a second Compose action to isolate the decimal remainder:

sub(float(string(triggerBody()?['ProductQuantity'])), outputs('Compose_truncated'))

3. Add a Condition action checking

greater(outputs('Compose_remainder'), 0).

4. In the Yes branch, set your integer variable to:

add(outputs(‘Compose_truncated’), 1).

5. In the No branch, set it to unchanged

outputs('Compose_truncated')

This gives you true ceiling behavior: 4.01 becomes 5, and 4.0 stays 4. For the opposite rule (always round down no matter what, useful for inventory allocation where you can never promise more units than you actually have), just skip the Condition entirely and use Method 1’s truncation expression on its own, since truncating a positive float already behaves exactly like a floor operation.

If your numbers can also be negative, be careful here. Truncation on negative floats rounds toward zero (-4.7 becomes -4, not -5), which is mathematically different from a true floor. Add an extra Condition checking less(triggerBody()?[‘ProductQuantity’], 0) if negative values are realistic in your data and the direction matters.

Putting the Float to Integer Conversion to Work in a Real Flow

Here’s how this looks in the full Products inventory flow I mentioned earlier. Start with an automated cloud flow using the When an item is created or modified SharePoint trigger, pointed at your Products list. Add a Get items action if you’re processing multiple rows in bulk, or work directly off the trigger output if you’re handling one item at a time.

Wrap the item’s ProductQuantity value in the Method 2 expression inside a Compose action, since rounding to nearest is the safest default for quantity data pulled from Excel:

int(formatNumber(triggerBody()?['ProductQuantity'],'F0'))

Then add an Update item action, filling in the Site Address, List Name, and the ID from the trigger. In the ProductQuantity field, reference the output of your Compose action instead of the raw trigger value.

When the flow runs, the list gets a clean whole number every time, and the validation errors disappear. If your list also tracks a running count, the same conversion habit helps when you increment an integer field in a SharePoint list using Power Automate, since that action also expects a clean whole number rather than a float.

If you’re processing an entire list instead of reacting to one change, wrap this same logic inside an Apply to each loop fed by Get items, and add a Select data operation beforehand to map just the ProductQuantity column, which keeps your Apply to each lighter and easier to debug. This pattern also works well as a scheduled cloud flow that runs nightly to clean up any float values that snuck into the list from other integrations during the day.

It’s also worth setting proper trigger conditions in Power Automate on this flow, so it only fires when ProductQuantity actually changes, instead of running the conversion logic on every single list update regardless of which column changed.

And if you’re extracting the number from a text string before running any of these expressions, the same substring function approach used to isolate parts of text works well alongside split() when your source data is messier than a clean Number column.

Things to Keep in Mind

• int() truncates, it never rounds. Don’t assume int() gives you “nearest whole number” behavior. If you need rounding, pair it with formatNumber as shown in Method 2, or you’ll quietly lose accuracy in every calculation downstream.
• formatNumber always returns a string. Even though the output looks like a number, you must wrap it in int() before using it in math expressions or writing it to a Number or Whole Number column, or you’ll get a type mismatch error.
• SharePoint Number columns still display decimals unless you change the column setting. Converting the value in your expression doesn’t stop the list column itself from showing “24.0” if the column’s decimal places setting is still set above zero. Check the column configuration, not just your flow logic.
• Watch your negative numbers. Truncation rounds toward zero, not down, so -4.7 becomes -4, not -5. If your data can include negative values and direction matters for the business rule, add a Condition to handle that case separately, as shown in Method 3.
• Test with real edge cases, not just clean numbers. Run your flow with values like 0.0, negative decimals, and numbers just under a whole number (like 9.999) before trusting the expression in production. I’ve seen flows pass testing with tidy numbers like 5.5, then fail the first time a real record came through as 0.0001.
• Build in error handling around type conversions. If ProductQuantity can sometimes be blank or come through as text instead of a number, your int() or float() expression will fail the entire run. Add a Condition action to check for blank or non-numeric values before the conversion step, or wrap the action in a scope with proper error handling in Power Automate so one bad row doesn’t stop the whole flow.
• Keep your expressions in Compose actions, not buried in destination fields. Typing a long nested expression directly into the Update item field makes it painful to debug later. Build it in a standalone Compose action first, confirm the output looks right, then reference that Compose output in your destination action.

Frequently Asked Questions

You May Also Like

Convert float to integer in Power Automate always comes down to picking the right expression for the job, whether that’s a quick int() truncation, a formatNumber-based rounding, or custom ceiling logic built with a Condition action. Start with Method 2 as your default for anything involving money or counts, and reach for Methods 1 and 3 only when the business rule specifically calls for truncating or forcing values in one direction. I hope you found this article helpful.

• convert a string to a float value in Power Automate
• isFloat function to validate numeric input in Power Automate
• format a number as currency in Power Automate
• extract a number from a string in Power Automate
• auto-generate a serial number in Power Automate

Bijay Kumar

After working for more than 18 years in Microsoft technologies like SharePoint, Microsoft 365, and Power Platform (Power Apps, Power Automate, and Power BI), I thought will share my SharePoint expertise knowledge with the world. Our audiences are from the United States, Canada, the United Kingdom, Australia, New Zealand, etc. For my expertise knowledge and SharePoint tutorials, Microsoft has been awarded a Microsoft SharePoint MVP (12 times). I have also worked in companies like HP, TCS, KPIT, etc.