Working with date and time fields in Microsoft Dynamics 365 can be tricky, especially when you’re using additional automation tools, such as Microsoft Flow or Azure Logic Apps, to facilitate your business processes. Recently, I worked with two different date and time fields on two entities that were not directly related inside of Dynamics. One field was a date only field with time-zone independent as the behavior. In this example, the field is called “Activation Date” is on the Account entity.
The other field was a custom field on a custom entity installed by a 3rd party solution. This field was also a date only field with user local as the behavior. This field is called “Asset Activated On” and is on the custom entity called Asset.
I used a Logic App to trigger on the Account record, perform other logic steps, and then create Asset records. While creating the Asset record, the “Asset Activated On” field was populated with the same date that appeared in the “Activation Date” field in the Account record.
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
However, when I ran the Logic App, I saw a date on the Asset record that did not match the date on the Account record.
This happened because the behaviors of the fields did not match. The “Activation Date” field is a date only field but, as the Microsoft documentation explains, the field is still storing a time of 12:00AM so the “Activation Date” is 8/12/19 at 12:00AM. This is converted automatically to my user local time zone of Central Standard time by subtracting five hours. This means the date displays as 8/11/19 in the “Asset Activated On” field.
My requirement is to have the same date displayed in those two fields, so I needed to solve this time conversion issue. One way to fix this would be to alter the field behavior of the “Asset Activated On” field. I did not want to change this behavior because I did not know if the 3rd party solution was using this field for any other logic or automation. There was a risk that changing the field behavior could create bugs in that logic. Instead, I solved this problem in the Logic App using the provided functions for dates. I used the convertToUtc function to control the time element of my field. The function adjusted the time by five hours for Central Standard Time so that the date displayed the correct date in Dynamics.
The full function statement:
convertToUtc(triggerBody()?[‘prft_activationdate’],‘Central Standard Time’,‘yyyy-MM-ddTHH:mm:ssZ’)
The first parameter is the source field for the timestamp, the second parameter is the time zone, and the third parameter is an optional timestamp format. See the Microsoft documentation for more examples and functions.
When I ran the Logic App again, the date is now displaying correctly in my environment.
If you have users in multiple time zones, you should adjust the time zone parameter so that the date displays the same in all your users’ time zones.