Find out why the Appointment Form refreshes upon record save and executionContext.getEventArgs().preventDefault() is not working
Issue 1: The Appointment Form refreshes upon record saveI received a report recently from one of the customers that the system triggers a form refresh upon auto-save of an Appointment record. On rare occasions, unexpected form refresh due to auto-save causes some data loss. This usually happens when the user is entering a long text in the multiline textbox and the last few bits of the text were lost and no longer there when the form is refreshed.
Upon further investigation, we found out that it only happens in the Appointment form and the form refresh happens regardless of whether it is manual save or auto-save. The rest of the entity forms behave normally and lock the screen with white transparent overlay upon save event occurs. I checked out the behaviour of the Appointment form in the other environments and, strangely enough, it happens in most of the other Dynamics 365 environments but not in the model-driven app of my personal CDS environment.
Issue 2: executionContext.getEventArgs().preventDefault() is not working only in Appointment Form
We have a logic in onSave event of the Appointment form to validate the form data and stop the user from saving the record. After one of the service updates, the users reported that the Appointment form validation is no longer working. Even though preventDefault() method is invoked in the OnSave event, the system proceeds to save the form anyway.
Issue 3: The User is getting Scheduling Alerts for conflicting appointments
In this project, one of the requirements is to allow the back-office users to create appointments on-behalf of/for the social workers with their clients. When the back-office user creates two appointments at the same time for different social workers, the system prompts a scheduling alert (see screenshot below), and that is because the current back-office user is set as the Organiser of the Appointment and the system treats that as a conflicting appointment, thus the alert. But in this particular scenario, the Organisers (who is the back-office user) don’t necessarily attend the appointments themselves, and even though there is an option to ignore and save the record, it can be a bit annoying to always see this prompt when the back-office user creates a lot of overlapping appointments. And because of that, the users requested for that warning message to be removed.
Microsoft SupportRegarding Issue #1, we were not able to figure out why the Appointment Form refresh occurs only in some environments. And so, we raised a ticket with Microsoft Support, and we got a response from the Microsoft developers. The developers are aware of the issue and said that this is by design at the moment since they do not have a plan to fix this just yet. In short, this is caused by the Scheduling Engine on the appointment form which shows the scheduling alert from Issue #3 above. The rest of the response is a bit technical - for enabling scheduling engine, Microsoft developers had to stop typical form infra save and register new OnSave handlers because the form infra save handler currently don't return promise (this is related to async programming), and hence it's different from other entity form save events where the page is not refreshed upon save.
That explains why we experience the Appointment form refresh behaviour in the environments where the scheduling engine is enabled but it behaves like a normal form in my CDS environment where the scheduling engine is disabled.
After resolving this issue #1, we found out that we were not able to replicate the issue #2 anymore. It turned out to be that issue #2 is also related to the scheduling engine and the product team confirmed it as a known issue. The quick mitigation before the permanent fix is rolled out is to disable the scheduling FCB. (see below)
FCB.Editor (Feature Control Bits) tool solutionTogether with Microsoft’s explanation, we were provided with one managed solution .zip file which needs to be imported to disable the scheduling engine. Once the solution is imported, we can now see the configuration page of the solution (see screenshot below) where we can specify the name of the Feature Control Bits and set the true/false value.
At the moment, there are 3 feature control bits in our organisation.
<features> <feature xmlns:i=\"http://www.w3.org/2001/XMLSchema-instance\"> <name>FCB.GUIDEDHELP</name> <value>true</value> <location>Organization</location> <lastupdate>2019-10-23T01:52:51.0498136Z</lastupdate> </feature> <feature xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> <name>FCB.SHAREPOINTS2S</name> <value>true</value> <location>Organization</location> <lastupdate>2018-05-21T04:29:55.4609788Z</lastupdate> </feature> <feature xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"> <name>FCB.APPOINTMENTSCHEDULINGINUCI</name> <value>true</value> <location>Organization</location> <lastupdate>2019-10-23T01:52:51.0498136Z</lastupdate> </feature> </features>
What is the impact of disabling the scheduling engine?The scheduling engine is responsible for alerting the users if they double book an appointment. Disabling this scheduling engine feature/FCB means that any alerts/notifications will no longer show up for the user and the system will always save it irrespective of their schedule. Other than that, there will be no other impact.
In our scenario, the users wanted to disable the scheduling alerts in the first place so that we just disabled it using the FCB.Editor and that resolved both issues.
If you encounter a similar issue and scheduling alerts are not necessary for the business, you can contact Microsoft Support to provide you with the tools (FCB.Editor) and instructions to disable the scheduling engine.