Field – Microsoft Power Platform & Dynamics 365: It's Fascinating

In this article, we deep dive into the Microsoft Dynamics 365 Customer Engagement Date and Time field type, as well as explore the implications of this field type on SQL Server Reporting Services (SSRS) reports depending on the behavior and format selected. We demonstrate how to make SSRS reports to display Date and Time fields in the user’s time zone. Also, we look at how the different behaviors and formats of the Date and Time field type are stored in the SQL database. The included use case provides a real world scenario of where the information in this article came in handy.

Use Case

Inspiration

Recently on a client engagement, a bug was raised on a couple of SSRS reports I had built a few months ago. A date field on the reports was displaying the next day i.e. if a record was approved yesterday, the report was showing that it was approved today in some cases. Looking at the records from the Dynamics 365 user interface, i.e. views, Advanced Find and forms, the field was displaying the correct date despite the SSRS reports were showing that same date as the next day. This behavior was only observed on some of the records created by the clients.

I thought of sharing the problem solving approach and tools I used to resolve this bug with the hope the it may help another Microsoft Dynamics 365 software developer in the future.

What was going on

The field in question it is a Date and Time field but the reports are configured to show the date part of the field only, as per the requirements. After investigations, it turned out that the SSRS reports were consuming a Date and Time field type (Behavior: User Local. Format: Date and Time), without translating it into the user’s time zone. Therefore, if a user approved a record between 8pm and Mid-night EST, the date of approval would show up on the SSRS report as the following day. This is because if a Date and Time field type’s behavior is set to User Local, the actual data is store in UTC time but translated to the user’s time zone when displayed to the user in the Dynamics 365 user interface. Unlike the Dynamics 365 user interface, SSRS reports do not automatically provide the translation to the user’s time zone but is can be implemented as shown in the SSRS Reports section below. Therefore, the source of the discrepancy between the date seen by users in Dynamics 365 user and what was being shown in the report lies in the fact that the Dynamics 365 user interface was translating the UTC date into the user’s local time while the report was showing the date as it was recorded in the SQL database. As the client is based in the EST, the bug could only be replicated, under the same conditions, between 8pm and Mid-night EST, when EST and UTC exist on two calendar dates.

Some of the client’s employees was creating the data between 8pm and Mid-night EST. As the field’s behavior is set to User Local, in the four hours time window (8pm to Mid-night EST), UTC and EST are on two different dates, and records approved in period will stored on the following day in UTC, which the database time for User Local behavior fields.

The Tools to Debug the Problem

View the Behavior and Format of Date and Time FIelds

Open the Date and Time field in the Dynamics 365 solution and see how it is saved:
Date and Time field's Behavior and Format

Date and Time Fields: Behavior and Format

The table below shows the different behaviors and formats of Date and Time fields in Dynamics 365, and well as their implications.

Behavior	Format	Changing field’s behavior
User Local Note: This is the behavior of all date and time fields in the previous releases. – The field values are displayed in the current user’s local time. – In Web services (SDK), these values are returned using a common UTC time zone format.	Date Only – or – Date and Time	In the user interface (UI), you can change certain out-of-the-box entity field’s behavior from the User Local to Date Only. For a list of entities and fields, see Changing the field behavior to Date Only on upgrade. You can change the custom entity field’s behavior from the User Local to Date Only or to Time-Zone Independent. Changing the field behavior affects the field values that are added or modified after the field behavior was changed. The existing field values remain in the database in the UTC time zone format. To change the behavior of the existing field values from UTC to Date Only, you may need a help of a developer to do it programmatically. More information: Convert behavior of existing date and time values in the database. Warning: Before changing the behavior of a date and time field, you should review all the dependencies of the field, such as business rules, workflows, calculated fields, or rollup fields, to ensure that there are no issues as a result of changing the behavior. After changing the behavior of a date and time field, you should open each business rule, workflow, calculated field, and rollup field dependent on the field that you changed, review the information, and save it, to ensure that the latest date and time field’s behavior and value are used. You can restrict modifying the field’s behavior, by setting the CanChangeDateTimeBehavior managed property to False. More information: Set managed property to change date and time behavior
Date Only – The concept of a time zone isn’t applicable to this behavior. The field values are displayed without the time zone conversion. – The time portion of the value is always 12:00AM. – The date portion of the value is stored and retrieved as specified in the UI and Web services (SDK).	Date Only	The Date Only behavior can’t be changed to other behavior types, once it’s set.
Time-Zone Independent – The concept of a time zone isn’t applicable to this behavior. The field values are displayed without the time zone conversion. – The date and time values are stored and retrieved as specified in the UI and Web services (SDK).	Date Only – or – Date and Time	The Time-Zone Independent behavior can’t be changed to other behavior types, once it’s set.

Source: Microsoft

Date and Time fields in Dynamics 365 User Interface vs. SQL Database

Dynamics 365 User Interface: Date and Time fields

Here are the different possible combinations of storing simple dates and time data in Dynamics 365 (on a classic interface form for the Contact entity):
Date and Time fields on a Form

SQL Database: Date and Time fields

In this section, we will look at how the date and time fields in the previous section are stored in the database. The date and time fields are on the Contact entity (i.e. ContactBase table in my Dynamics 365 SQL database). Querying for the specified columns in the table where the full name is ‘Peter Parker’:

SELECT TOP (10)
       [FullName]    
      ,[hos_uselocal_dateonly]
      ,[hos_uselocal_dateandtime]
      ,[hos_dateonly_dateonly]
      ,[hos_timezoneindependent_dateonly]
      ,[hos_timezoneindependent_dateandtime]
  FROM [House_MSCRM].[dbo].[ContactBase]
  WHERE FullName = 'Peter Parker'

See the results below:
Viewing Date and Time fields in the datebase

From the database results above, it is worth noting:

Behavior of User Local and Format of Date Only: these fields are always stored as 4am in my database in EST, which is 12am UTC.
Behavior of User Local and Format of Date and Time: in my time zone, i.e. EST, these fields are always stored 4 hours ahead, i.e. UTC time, in the database. In contrast, in the user interface, this field always shows the data in my time zone.
Behavior of Time Zone Independent and Format of Date and Time: stores the data in the database as inputted in the user interface and does not respect time zones.

SSRS Reports: Display Dates and Time in the user’s time zone

There are two ways to create SSRS Reports for Dynamics 365. You can create a report in Dynamics 365 using the Report Wizard, export it and add to your Report Server Project in Microsoft Visual Studio IDE, with the built-in fields and parameters, from Dynamics 365. Alternatively, you can take the opposite path of creating a blank Report Server Project in Microsoft Visual Studio IDE, connecting to Dynamics 365, and adding the built-in fields and parameters as needed. If you take the former approach, you will get the built-in fields and parameters in Visual Studio, similar to the image below:
Visual Studio - built in fields and parameters

To translate UTC date and time data, for User Local behavior, in the SQL database into the user’s time zone, you have to use the SSRS Report formula below, where “CRM_UserTimeZoneName” is a parameter and <SSRSDateAndTimeField> is name of your Date and Time field in SSRS:

=Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(
<SSRSDateAndTimeField>, Parameters!CRM_UserTimeZoneName.Value)

“CRM_UserTimeZoneName” is a parameter passed in from Dynamics 365, containing the user’s time zone. The function “Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime” iconverts UTC time to the user’s time zone. Therefore, when the user runs the report, they will see the date and time data in their time zone, despite it is stored as UTC by default in the SQL database.

Here are some application examples, where “Fields!hos_uselocal_dateandtimeValue.Value” is the SSRS date and time field in Visual Studio:

Display User Local Date and Time SSRS data field in the user’s time zone (showing both date and time data):

=Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(
Fields!hos_uselocal_dateandtimeValue.Value, Parameters!CRM_UserTimeZoneName.Value)

Display User Local Date and Time SSRS data field in the user’s time zone (showing the date component only without the time component of the date, in the format dd/MM/yyyy):

=Format(CDate(Microsoft.Crm.Reporting.RdlHelper.DateTimeUtility.ConvertUtcToLocalTime(Fields!hos_uselocal_dateandtimeValue.Value,
Parameters!CRM_UserTimeZoneName.Value)), "dd/MM/yyyy")

Dynamics 365 Online: Accessing the contents of your SQL database

In Dynamics 365 Online, you do not have access to the SQL database that hosts your Dynamics 365 organization. However, Microsoft allows you to access the data in your SQL database by duplicating and syncing to Microsoft Azure. From Azure, you can connect to duplicated SQL database and be able to run the SQL script in this article. For more details duplicating and syncing your Dynamics 365 online SQL database to Microsoft Azure, see: Microsoft Dynamic 365 Data Export Service: Duplicating and Syncing SQL database in Azure

In version 9 of Dynamics 365 / CRM, Microsoft introduced the Custom Control Framework, which gives Dynamics 365 customizers and developers more options on how to display fields and data-sets, such as views. The Custom Control Framework offers a wide range of aesthetically appealing displays, enabling you to transform regular fields and data-sets into more appealing visualizations that are likely to increase user engagement and enhance user experience.

Examples

The default display for a numeric input field, i.e. Whole Number, Decimal, Currency, Floating Point Number, is:

Using the Custom Control Framework, you can transform this regular numeric input field into other displays such as Number Input, Arc Knob, Radial Knob, Linear Gauge, Linear Slide, Star Rating, among others.

Depending on the type of input field, different Custom Control Framework displays are available. For an Option Set field, the regular display is:

Using the Custom Control Framework’s Option Set, it can also be displayed as tiles:

How to Implement the Custom Control Framework

Step 1: Go to the edit mode of the entity’s form that you wish to apply the Custom Control Framework to. In the example below, I will be editing the Account entity’s Account form.

Step 2: Click on the field you would like to apply the Custom Control Framework to. In the ribbon, click on ‘Change Properties’.

Step 3: In the Field Properties window that pops up, select the ‘Controls’ tab.

Step 4: Click on “Add Control…”. Then select the control you would like to apply (1 – image below). Having selected the control you would like to apply, click ‘Add’ (2 – image below).

Note: In the example below, I am applying the Custom Control Framework to a numeric field.

Step 5: Set the properties of the control. Select the devices you want your control to be displayed on i.e. Web Browser, Phone, Tablet (1 – image below). Enter the control’s properties i.e. Min, Max and Step values (2 – image below). Click ‘OK’ (3 – image below).

In (2 – image above), you can bind the Min, Max and Step values to a static value (A – image below) or to another field (B – image below).

Step 6: Save and publish the entity’s form. You can now go and view the published version of the form to see your custom control in action.

Depending on the type of input field selected, different Custom Control Framework displays are available in Step 4 above. Also, the properties available in Step 5 are dependent on the type of input field selected . That is, the Custom Control Framework displays available for a numeric field are different from those available for an option set field.

Conclusion

As shown above, the Custom Control Framework offers organizations more options for displaying fields and has a nice aesthetic touch. However, like all tools, Dynamics 365 customizers and developers, have to assess their client’s needs and determine whether to use the default displays or the Custom Control Framework displays.

Tag Archives: Field

Microsoft Dynamics 365 and SSRS Reports: Dates and Time