Both of these are wait conditions used to delay processing in your flows. But what’s the difference? Let’s understand with an use case application.
They come under the Schedule Action:
DELAY – Adds a fixed delay before the next step in a certain unit of measurement. Thus just tell the count in 1,2,3…… & choose the desired unit.
Power Tip 1: Here I would like to point out that I think Microsoft has just included the “Month” option for the sake of completion, but you should never use it. Flows have a 30 days max runtime, so after that time, regardless of what step you are, the Flow will timeout. So defining anything above that time will never be executed. Its like a complete NO NO to use.
DELAY UNTIL- adds the delay until a specific timestamp. Thus add the timestamp in ISO8601 format.
Power Tip 2: The flow considers the Time in UTC timezone. Thus make sure to convert the Timezone to UTC before passing it in the delay until step. Below is the formula to help achieve this.
Power Tip 3: The format of the date and time is very important here. If you use any different format, you will find that the Delay Until step fails with the following error.
Now lets see the application.
Business Scenario: Remember the example we took in my BLOG38 , where in a Lead we could dispose it off as “Call back required”. Well you may save the Call back Time in units of measurements like 10 mins, 30 mins, 1 hour etc as the Business Requirement is OR at a particular Time which the customer asks for.
Let’s explore both of these scenarios here.
Scenario 1: Say we give the Call back Time in a span of duration(the unit is predefined here).
Thus we see that the Delay Steps waits for 2 minutes before the next step.
Scenario 2: The Customer gives a proper timestamp to call them back.
Thus we see that the Delay Until Steps waits for till it is 10:38(IST-5 hours 30mins) before the next step. PS: The time is in UTC
So now you know how it works, but still it has certain improvisation to be done.
Problem 1: If the target date or duration is more than a month, then the flow fail would fail as the 30 day limit would be breached.
Problem 2: If the entry has been updated after the initial flow had been initiated (e.g. the Lead calls back and tells to call him back after 5 mins instead of 15), the initial flow would still be running and therefore continue to wait for the original target date/time & the new one will trigger a flow too. As the Callback time is not revised and 2 flows are running simultaneously to perform a single task, we should stop the initial flow somehow.
Well if there’s a problem, there’s a solution.
Solution for Problem 1: In such cases use a scheduled flow and run that at proper intervals suiting the Business Requirement.
Solution for Problem 2: Here use a flag field and change it on change of the Disposition.
Now check this field before and after the Delay Action. If its different, terminate the flow otherwise create a Phone Call .
Test Scenario: I am disposing the Lead twice now- first one with 5 min interval & another with 1 min.
Output: The flow with 5 min interval terminates because the flow with 1 min interval already ran before it.
The Flow with 1 min interval runs successfully.
Hope it helps!
& the Power Quote of the day is:
“The Mind is everything! What you think is what you become”