Employees, mostly managers, send their emails using Outlook and other email services. But what if you want to create an email and send it to someone in their local time? Sending emails based on time zones is not available in Outlook, because it does not handle time zones. But Microsoft Flow can do the job.
Delaying emails to specific contacts is beneficial to employees whose jobs are mostly related to sending various emails to clients. By using Flow, you can create a trigger and series of actions that will enable you to achieve your goal in whatever processes you would like to attain. In this blog, we will talk about how you can delay emails based on time zones using Microsoft Flow.
In a nutshell, you must determine the primary contacts and delay sending email based on contacts’ local time in Flow. Take note that your accounts or entities must come from a model-driven app using the Dynamics 365 framework. Each account is based on time zones. In the screenshot samples below from the online conference this month, we used Australia as our local time and New Zealand time zone for the email destination. See screenshot below.
To start the process, go to Microsoft Flow to create a flow. You can start with a trigger as in the example below that says Manually trigger a flow.
Then create series of actions. The first action, 1.2 Retrieve Accounts, includes environment entry name, entity name, aggregation transformation filter query, order by, top count, and expand query. You are expected to use the CDS (Common Data Service) list records action for this part.
The second action is Apply to each that was renamed as 1.3 Identify Primary Contact. This action aims to identify the primary contact for each account stored in the model-driven app in Dynamics 365. Take note that the demo used another CDS list records action because it can help you with your query.
The list records are needed to get all the accounts and get only the contacts based on the ID of the primary contacts of the accounts.
The last step of flow is the Apply to each action renamed as 1.5 Delay email. Under the 1.5 Delay email action, you have the get location by address action. Under this action is the local time of contact action.
It is highly suggested that you use a parallel branching in this kind of flow. In our recent blog, Flow Studio founder John Liu mentioned parallel branching as among the five ways to make your flow run faster. Read the article here.
To delay sending the email based on the local time of the contact, you need to know the time zones, time in the contact’s time zone, and then based on their time zone you convert the contact’s local time back into UTC (Coordinated Universal Time), because that is the day and time format that the delay email action uses. Note: The Primary Contact has the same address as Account. Bing Maps action uses Address 1 details from Contact.
Inside the delay email action are Bing maps action that allows you to identify the longitude and latitude coordinates based on the address value. In the demo, the Address 1 value came from the Dynamics 365. Once the Bing maps action successfully executes, it will generate the latitude and longitude coordinates.
The next action, 1.7 Local time of Contact, is based on another Bing maps API request that will get the time zone based on an address provided using the latitude and longitude coordinates.
After that, you can proceed with the parallel technique. The reason for using the parallel branching technique is because the two paths (left and right) are independent on each other, which means the actions can happen at the same time.
Notice that the right side of the flow is the Compose action named as 1.9 Retrieve windowsTimeZoneID. This action is going to reference the window’s time zone by the copy that has been returned in the previous response, 1.7 Local time of Contact. See screenshot below for the expression.
Take note that you only want the windows time zone ID that is in the time zone object which is within the resources array whose parent is the resource set objects.
Under the 1.8 Retrieve LocalTime action on the left-hand side of the flow, you need to add two more Compose actions: 1.8.1 Split the date string and 1.8.2 Retrieve date only string. Basically, you will be displaying the date and time string value using the capital T (“localTime”: “2019-08-06T14:47:37”) and the date string value. See screenshot below.
The next action is converting time zone named as 1.10 Convert time zone. For this action, the base time will be based on the date that was retrieved by the Compose action, 1.8.2 Retrieve date only string.
In this action, add the recipient’s local time (for example, T09:44). The Flow uses this format string: yyyy-MM-ddTHH:mm:ssZ. The Source time zone is based on the time zone of the contacts of the local time zone (this is the output from the 1.9 Retrieve windowsTimeZoneID action that was identified in the Bing maps API request, 1.7 Local time of Contact. The destination time zone is set as UTC (Coordinated Universal Time) to allow conversion of the time into UTC.
The next action, 1.11 Delay until, is the converted time. This is where you can reference the converted time. Flow uses the converted time zone of the contact into UTC to ensure that it will only send email based on the recipient’s local time.
The next action, 1.12 Send an email, is where you will select value for the email destination, provide Subject of the email, and write your email in the body field.
Once you are done, hit Save & Test in your Flow dashboard. You can check your email to see how it worked. It should look like the screenshot below.
This topic was shared by Elaiza Benitez during the Microsoft Flow online conference that was held this month. Benitez is a Microsoft Business Applications MVP (Most Valuable Professional) and a functional consultant.
Aside from Benitez, who was the speaker for session 6, the other speakers of the conference were the following:
Shane Young, “Why I Love Microsoft Flow” (Session 1)
Melissa Hubbard, “Getting Started with Flow Approvals” (Session 2)
David Patrick, “Intro to the Common Data Service in Flow” (Session 3)
Anton Robbins, “Things to Know Before You Flow” (Session 4)
Sean Bugler, “Tell a Better Story with Flow” (Session 5)
Daniel Christian, “PowerApps and Flow for Social Media” (Session 7)
Tomasz Poszytek, “Scopes and Run After Actions” (Session 8)
Sandy Ussia and Daniel Laskewitz, “The Flow Pro Show” (Session 9)
Scott Shearer, “Flow for SP Designer Workflow Developers” (Session 10)
Sarah Critchley, “Flow, Model Driven Apps & Cognitive Services” (Session 11)
Gabriel (Galo) Corvera, “Flow + Teams + Adaptive Cards” (Session 12)
Devin Knight, “Power BI Streaming Data sets + Flow” (Session 13)
Haniel Croitoru, “You Have an Error in Your Flow? Let’s Deal with It!” (Session 14)
Vivek Bavishi, “Sending .vcf Contact Cards with Flow” (Session 15)
Joe Unwin, “Getting Started with Custom Connectors in Flow” (Session 16)
Geetha Sivasailam, “Microsoft Flow and Azure Dev Ops” (Session 17)
John Liu, “5 Keys to make your Flows run Insanely Fast” (Session 18)
There were 29,109 people who registered for the online conference, according to Microsoft Flow senior program manager Jonathon Levesque.
If you would like to watch all the eighteen sessions, click here.