Sonoma Partners Microsoft CRM and Salesforce Blog

Field Notes: Date/Time Issue with Business Rules and Dynamics Mobile

Today's blog post was written by Aaron Robinson, Solutions Architect at Sonoma Partners.

Over the years Microsoft has made tremendous improvements to its mobility story for Dynamics CRM, with modern apps available across all platforms today. However, we still don’t have true parity with what’s available on the desktop, and processing of JavaScript is one big area where the mobile app shows its limitations. While one can make the argument that parity is probably not the strategy, I would argue that there should at least be consistency. We saw a JavaScript issue in the previous version when referencing the Status Reason and Status fields which were resolved by the latest upgrade. Here is a case in point of a recently discovered issue which occurred after a D365 upgrade of the Dynamics CRM mobile app as tested on iOS.

In this example, we have a custom entity called Visits, which allow a user to create a visit record (similar to an appointment), and set a scheduled date and time for the visit. The form also contains a start and end time for the visit, to be completed after the visit occurs. Here we have also setup some business rules to enforce some logic on the date and time that can be entered for the actual visit start and end time as such:

  • Rule 1: If the schedule date and visit start both contains data, and the scheduled date is greater than the visit start, show an error message on the visit start field so the user can correct the time. Essentially, we are trying to enforce that a visit start time should always be equal or greater than the scheduled date and time.

  • Rule 2: If the schedule date, visit start, and visit end all contain data, and the visit start is greater than the visit end, show an error message on the visit end field so the user can correct the time. Same premise as above, but now between the visit start and end time. Logically your end time should not come before your start time.

Makes sense, right? So, let’s take a look at using this logic in both the web and mobile app.

In the screen shot below, I can move the visit start time before and after the schedule date, and the error message shows appropriately. The same happens with the visit end time, regardless of the time I use.

Aaronrobin1_750

In the mobile app, this appears to be the case as well.  I move the date/time back and forth, and everything appears kosher.

However, something odd happens around the noon hour for the visit end time.  In this example, I set the start time to 11:00am, and the end time to 11:59am. Supposing for a moment that I entered the visit end incorrectly, or I was setting it when the system clock time was actually 11:59am, I want to change the end time to 12:00pm.  When I click into the field to edit the time and change the hour to 12, the error message is flagged on the visit end field as being less than the visit start.

Aaronrobin2_750

Again, technically this is correct, because it’s now validating the time as 12:59 AM, as the rule fired right when I changed the hour. The problem here is that even if I change the AM to PM, the error message remains because the rule doesn’t appear to revalidate again. This was fairly easy to remedy as you could click out of the field and back in, or hit clear field and re-enter the time from scratch, but adds a couple of extra taps and it’s not exactly obvious to the average user.

We went back to the web app to test this out, and we do not experience the same behavior. So how did we resolve it? Simple re-creation of the business rule appears to address the problem. Given this was an upgrade, we figure we could rule out any upgrade related issues with JavaScript code by removing the rule and creating a new one, and it worked! We can now toggle the hour/minute or the AM/PM while the edit control is open and the rule will evaluate each time.

Topics: Microsoft Dynamics 365