In this WTF episode I go through how you can delay sending a birthday email based on the recipient's local time zone. It's pretty cool because you can't do this today with a Dynamics 365 workflow and I don't even think it is possible with the Microsoft Dynamics 365 for Marketing app either. Flow on the other hand can handle this requirement without development effort.
Quick recap
WTF episode 9 was about sending a birthday email to CDS Contacts when their day of birth and month of birth equals today's date. I mentioned that the Flow would not be suitable for Contacts in different time zones to my local time (Melbourne, Australia) because Contacts who are in a time zone behind my local time zone would get their email straight away.For example Contacts based in Seattle would get their birthday email a day early because of how Melbourne is 19 hours ahead. Not ideal to be greeted a day early.
WTF episode 10 paved the way on how to identify a Contact's local time zone where the address information stored in CDS was referenced in the Bing Maps Get Location by Address action followed by identifying the time zone through a Bing Maps time zone API using the latitude and longitude returned from the Bing Maps action. I also showed you how to retrieve the windowsTimeZoneId property form the JSON response.
Combing the two WTF Flows
Actions in both of the Flows can be used in a single Flow to delay sending a birthday email with some minor adjustments and a couple of extra actions. But first, learnt something new from Natraj who is the guy behind Chrome Level Up for Dynamics 365/CRM, a MVP and also currently a colleague 😁
Formatting date and time
In the daily recurrence schedule action you specify the time zone and the start time.
In the Flow docs.microsoft site it's slightly misinformed which is what I learnt from Natraj. If you enter 'Z' in the start time field of the action it will ignore the time zone entered and use UTC time zone. If you leave out the 'Z' it will respect the time zone entered. In my WTF episode 9 I was entering 'Z' and was entering a UTC date and time. A n00b mistake on my part because of how I was using 'Z' which was causing the action to use UTC, I thought you had to have the date and time in UTC because of what was outlined in the Flow doc. It's OK, everyone makes mistakes and you learn from it.
At the time of writing this blog post I also noticed someone else has commented the same thing in the Flow docs.microsoft page too - scroll down to the bottom.
Adjustment to a few steps
1. In the Compose action that converts the current UTC date and time to my local time zone of Melbourne, I am now interested in 'yyyy.' Previously in WTF episode 9 I was only returning 'MM-dd.'
2. In the Compose action that splits date values into an array, I can now reference 'yyyy.' The year value is set within another Compose action.
3. One thing I forgot mention in my vlog was that I am also using an Apply to Each action which will perform the actions based on the list of records returned. In this Apply to Each action is where I am checking the local time zone of the Contact through the HTTP action.
In the HTTP action that calls the Bing Maps Time Zone API Given location coordinates, find the time zone of the place, I am referencing the CDS Address 1 Latitude and Address 1 Longitude fields. Since this is a Flow that will be triggered on a daily basis, I have another Flow that triggers on create of a Contact where the Bing Maps Get Location by Address action is used to identify the Latitude and Longitude from their address information (show cased in WTF episode 9).
What I did to extend the Flow
Convert Time Zone action
I am using the Convert Time Zone action to set the desired time of when the birthday email should be sent. For example, I want the birthday email to send on the day of their birthday at 8am their local time. Remember, the date and time needs to be in the format of UTC date time format.
In order for the Base Time value to be set, this is where we have to reference outputs from actions in the Flow. The first one is to reference the compose action that contains the 'yyyy', followed by 'MM' and 'dd.' This makes up the date value. For the time value, simply enter the desired values for HH:MM such as 08:00 which represents 8am in the local time zone.
The reason why I adjusted the Flow by adding the Compose action that retrieves the 'yyyy' in the array is so that the Flow will continue to work whenever a new year starts 👍 No manual intervention required.
The reason why I adjusted the Flow by adding the Compose action that retrieves the 'yyyy' in the array is so that the Flow will continue to work whenever a new year starts 👍 No manual intervention required.
For the Format String value it has to be in the UTC Date time format.
For Source Time Zone value you will need to reference the local time zone of the contact which is achieved using the Compose action that has retrieved the windowsTimeZoneId value from the Bing Maps time zone API.
For the Destination Time Zone you need to use UTC. Why? A couple of reasons
- Flow uses UTC date and time for the Delay Until action which is what will be used to delay sending the email until it equals 8am in the recipient's local time zone
- Using UTC as the time zone will account for Daylight Savings Time of the local time if it is in affect. If you chose a non-UTC time zone such as Melbourne, it will be behind by 1 hour which is what I found when playing with this.
Your Convert Time Zone action should look like this:
Delay Until action
As mentioned earlier this action will delay sending the birthday email to the local time of the recipient based on the set date and time value in the converted Base Time from the Convert Time Zone action. Then simply add the Send Email action as seen in WTF episode 9.
Yay
The Flow will trigger as per the Daily Recurrence action. Flow will return the list of CDS Contacts whose day of birth and month of birth equals today's date and will send in their local time using the converted base time from the Convert Time. Pretty cool!
This screenshot shows what the UTC time is that represents Wellington Daylight Savings Time.
In Flow you can see that it had correctly converted the desired set time of 10.22pm (in Wellington (which was 8.22pm Melbourne time when I was vlogging). For a more realistic time if this was a live Flow, this would be set to 8am.
What you need to know
Apply to Each action UI might trip you up
I tripped. I fell. I swore. Haha yeah nah, I was fine but I was scratching my head because I was confused 🤔
I was confused from the UI of the Apply to Each action. When I was testing my WTF Flow I had a contact in Seattle, USA and a contact in Wellington, New Zealand. I set the Base Time in the next few minutes for the Wellington time zone so that I could check it does work. When the Flow ran the Apply to Each action appears grayed out.
I interpreted this as it's not working for either contact. I was watching the clock like a hawk and every time the delayed time was met for the Wellington time zone, I was expecting the record in the Apply to Each action to show green ticks. This puzzled me and I was also frustrated with it because I was thinking "Oh man I am so close in getting this working but it's showing as grayed out."
Enter John Liu my Flow guardian angel. He explained to me that it would have processed the record in spite of the lack of visual cue. Until all records within the Apply to Each action have completed being processed you won't see the green ticks or red crosses.
When I experiment with Flow I normally create each action one by one and run the Flow to check each action will succeed so that I know what I need to fix if there's a problem before configuring the next action. My Send Email action was the last step, I didn't know if it was actually sending since I was not able to know for sure if the Delay Until action was working as Seattle is 19 hours behind my time. The Apply To Each was appearing grayed out so it confused me.
As soon as I added the Send Email action and ran the Flow again, John was right - the email does send because the record meets all the action criteria even though the Apply to Each is greyed out.
It will show the green ticks or red crosses when ALL records in the Apply to Each have completed being processed. Eventually when 10.21pm in Seattle was met 19 hours later, the Apply to Each action displays the comforting green ticks as the email sent and no other record needed to be processed.
It will show the green ticks or red crosses when ALL records in the Apply to Each have completed being processed. Eventually when 10.21pm in Seattle was met 19 hours later, the Apply to Each action displays the comforting green ticks as the email sent and no other record needed to be processed.
Makes sense but at the same time the UI confused me. It would be good if the actions within the Apply to Each action has visualisation so that you know what has succeeded or failed instead of waiting till all actions of all the records in the liast have been completed. Please note this is when a Delay Until action is used within an Apply to Each action and I also suspect will also occur when a large volume of records are being processed.
Flow concurrency
Another thing you can do with Apply to Each is enable what you call Concurrency. It means that records within the Apply to Each action can be processed simultaneously rather than one at time. I enabled concurrency in my Apply to Each action. I'm going to direct you to John Liu's blog post for further information on the Apply to Each Concurrency setting.
Summary
You can send a birthday email to a recipient and ensure they get it at a set time within their local time zone. The recipient won't get it at weird hours of the day or a day early. Using a combination of Flow connectors it's possible without code and even accounts for Daylight Savings Time of the recipients local time zone.
Till next time, toodles.
0 comments:
Post a Comment