Power Automate: getFutureTime function

The "getFutureTime" function answers one question, and it answers it in a single line. "What will the timestamp be, a while from now?" You give it a number and a unit, and it hands you back a timestamp that far into the future. Deadlines, reminders, expiry dates, and "anything due in the next 7 days" filters all start here.

It's a convenience wrapper. Underneath, it's the "utcNow" function plus the "addToTime" function rolled into one, which is exactly why people reach for it. It also has a mirror twin called "getPastTime" that does the same thing in the other direction. Let's look at how it works, where it earns its keep, and the two or three places where it quietly does something you didn't expect.

Where to find it?

You can use the function anywhere an expression is supported. In practice it shows up most often inside a "Compose" action, an "Initialize variable" action, a "Condition" action, or in the filter query of an action that fetches records.

Let's look at how to use it.

Usage

The "getFutureTime" function takes two required parameters and one optional one:

getFutureTime(<interval>, '<timeUnit>', '<format>'?)

Notice that the interval is a number and has no quotes around it, while the unit is text and does. Mixing those up is the single most common way to make this function fail.

The simplest possible example asks for the timestamp five days from now:

getFutureTime(5, 'Day')

If the current moment is 2026-07-14T09:00:00.0000000Z, this returns 2026-07-19T09:00:00.0000000Z. Note that the time of day comes along for the ride. You asked for five days from now, not for the start of the day five days from now.

Using a custom format

The third parameter shapes the output, and it's the one you'll want whenever the value is going in front of a person:

getFutureTime(5, 'Day', 'D')

This returns Sunday, July 19, 2026. You can also build your own pattern when you need something specific:

getFutureTime(1, 'Week', 'dd-MM-yyyy')

That returns 21-07-2026. The formatting rules are the same ones the "formatDateTime" function uses, so anything you already know from there applies here.

Using it in a filter query

This is where the function really pays off. If you want every item due in the next 7 days, you can build both ends of the range without a single extra action:

DueDate ge '@{utcNow()}' and DueDate le '@{getFutureTime(7, 'Day')}'

The "greater than or equals" operator and its counterpart bracket the range, and the two expressions supply the boundaries. One line, no variables, no loops.

Using a dynamic interval

The interval doesn't have to be hard coded. If the number of days lives in a variable or a column, feed it in through the "int" function so it arrives as a number rather than as text:

getFutureTime(int(variables('DaysUntilDue')), 'Day')

Let's break that down:

• variables('DaysUntilDue') reads the variable, which almost certainly holds a string.
• int(...) converts that string into a proper integer, which is what the first parameter demands.
• 'Day' is the unit, quoted because it's text.

Real-world examples

An expiry date for a document

Joana uploads a policy document and it should expire a year from the day it landed. Rather than working out the date by hand, you stamp it as the file is created:

getFutureTime(1, 'Year', 'yyyy-MM-dd')

This gives you a clean 2027-07-14 to write straight into the expiry column, with no time component muddying the comparison later.

A reminder Flow that runs every morning

You have a scheduled Flow on a "Recurrence" trigger that emails people about tasks due in the next three days. The filter is the whole Flow:

DueDate le '@{getFutureTime(3, 'Day')}' and Status ne 'Complete'

Because "getFutureTime" is evaluated fresh on every run, the window slides forward automatically. You never touch it again.

An escalation deadline

Manuel opens a support ticket and the team has 48 hours to respond. You store the deadline on the item at creation time:

getFutureTime(48, 'Hour')

Later, a second Flow can compare that stored deadline against the current time and escalate whatever has gone past it.

Non-intuitive behaviors

Here are the behaviors that catch people off guard with the "getFutureTime" function.

It is always relative to UTC, never to your local time

"Now" means "now in UTC", because that's what the function is built on. This is fine most of the time, and then it isn't.

Say it's 23:00 on Monday in Lisbon during the summer, which is 22:00 UTC. You call getFutureTime(1, 'Day') expecting Tuesday, and you get Tuesday, so all is well. But swap the time zone for one that sits behind UTC and the same call at 20:00 local on Monday in California is already Tuesday in UTC, so "one day from now" lands on Wednesday. Anything driven by a local business day needs the conversion applied afterwards, using the "convertFromUtc" function or the "Convert time zone" action.

It re-evaluates in every action

The current moment is read when the expression runs, not when the Flow starts. Two actions calling getFutureTime(1, 'Day') a few seconds apart will produce two different timestamps, and if the Flow happens to be sitting on a "Delay" action or waiting on an approval in between, those few seconds can become hours.

Whenever the same future timestamp is needed more than once, calculate it a single time into a variable or a "Compose" action and reference that everywhere else. It costs you one action and buys you consistency.

Months and years clamp to the end of the month

Add one month to January 31 and you get February 28, not March 3. The underlying date maths refuses to spill over into the next month, so it clamps to the last valid day instead.

This is almost always what you want, but it is not reversible. Adding a month and then subtracting a month does not necessarily return you to where you started, so don't build logic that assumes it does.

The output keeps the Z, but only with the default format

The default o format returns something like 2026-07-19T09:00:00.0000000Z, and that trailing Z is what tells every downstream system the value is UTC. The moment you pass a custom format, the Z is gone unless you put it back.

That matters most in filter queries, where a value without a Z is interpreted as the site's local time and quietly shifted. If you're filtering, either use the default format or make sure your pattern ends the way the receiving system expects.

Negative intervals work, though nobody documents it

Passing a negative number sends you backwards, so getFutureTime(-5, 'Day') behaves like a call to "getPastTime". It works, but the expression now reads as the opposite of what it does, and the next person to open your Flow will have to stop and think about it. Use "getPastTime" when you mean the past.

Limitations

It cannot start from any moment other than now

There is no parameter for a starting timestamp, and there is no way to add one. If the starting point is a due date, a created date, or anything else that isn't the current moment, this is the wrong function and "addToTime" is the right one.

The units are fixed, and quarters are not among them

You get Second, Minute, Hour, Day, Week, Month, and Year. Anything else has to be expressed in terms of those. A quarter is three months, a fortnight is two weeks, and a working day is not expressible at all, since the function has no idea that weekends exist.

The result is a string, not a date

The output is text, so you cannot do arithmetic on it directly. If you need to compare or measure, run the value through the "ticks" function to get a number, or use the "dateDifference" function when you want the gap between two timestamps.

Expression size limits

As with every Power Automate expression, you have a ceiling of 8,192 characters. Nesting a few of these inside a larger filter query eats into it faster than you'd think, so break long expressions into "Compose" actions.

Troubleshooting Common Errors

The function expects its first parameter to be an integer

Cause: You quoted the interval. getFutureTime('5', 'Day') passes the text 5 where a number is required, and the same thing happens when the value comes from a variable or a column, since those usually arrive as strings.

Solution: Drop the quotes on a literal, and wrap a dynamic value in the "int" function.

getFutureTime(int(triggerBody()?['DaysAhead']), 'Day')

The provided time unit is not valid

Cause: The unit isn't one of the seven the function accepts. Days, days, Mins, and Months in the wrong shape are all common, and so is forgetting the quotes entirely.

Solution: Use the exact singular, capitalized names. Second, Minute, Hour, Day, Week, Month, Year. Nothing else will do.

The filter query returns nothing, or returns everything

Cause: The timestamp you generated doesn't match the shape the source expects. A custom format that stripped the Z is the usual culprit, and comparing a date-only value against a column that stores a time is a close second.

Solution: Use the default format inside filter queries so the Z survives, and prefer the "lower than" operator and its siblings over an exact equality check on a date and time column.

DueDate le '@{getFutureTime(7, 'Day')}'

The date is a day out from what you expected

Cause: The UTC baseline. Late in the local evening, or early in the local morning, "now" in UTC is already on a different calendar day than the one on your wall.

Solution: Convert to the local time zone after doing the maths, not before, using the "convertFromUtc" function.

Recommendations

Here are some things to keep in mind when using the "getFutureTime" function.

Calculate once, reference everywhere

If the same future timestamp is used in more than one place, work it out a single time into a variable and reuse it. You get one value instead of several slightly different ones, and debugging becomes a matter of looking at one action rather than hunting through five.

Say what you mean with units

Reach for the unit that matches the business rule rather than the one that's convenient. "Two weeks" is getFutureTime(2, 'Week'), not getFutureTime(14, 'Day'), even though they agree today. When someone later changes the rule to "a month", the intent in the expression is already clear.

Keep the default format for machines

Pass a format string when a person is going to read the value, and leave the format alone when a system is. The default carries the Z and the full precision, which is exactly what filter queries, date columns, and comparisons want.

Prefer "getPastTime" for the past

It exists, it's clearer, and it costs nothing. A negative interval works, but reading getFutureTime(-30, 'Day') in six months will make you pause, and expressions that make you pause are expressions that get broken.

Always add a comment

Adding a comment will help others understand your expression. Say what the window means in business terms, because "7 days" in the code rarely explains why it's seven and not five.

Final Thoughts

The "getFutureTime" function is a small piece of convenience that removes a surprising amount of clutter from date logic. One line gives you a deadline, an expiry, or the far end of a filter window, and it stays correct on every run without you touching it. Just keep the two rules in mind. It always counts from now in UTC, and it re-evaluates every time it runs. Respect those, and it will do exactly what you asked, every time.

Sources

• Microsoft's getFutureTime function reference
• Reference for functions in workflow expressions, Azure Logic Apps and Power Automate
• Standard date and time format strings
• Custom date and time format strings

Back to the Power Automate Function Reference

Photo by Hadija on Unsplash