Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
With Unified Service Desk (USD) for Microsoft Dynamics CRM we have an event called RefreshRequested, but what does this event do and when might we use it? I wanted to find out so I investigated ….
The reference guide on the Microsoft site stated the following about RefershRequested.
Source : https://msdn.microsoft.com/en-us/library/dn864976.aspx
This suggested that the RefreshRequested event would be triggered when firing a Refresh action OR the user pressing F5. However, this didn’t quite match the behaviour I observed.
What actually happened was that firing a refresh action triggered the RefreshRequested event but pressing F5 didn’t. This might be a product issue with the particular USD version I was using. (My Unified Service Desk version was 188.8.131.526.)
As a test I added an action to the RefreshRequested event of my Contact tab. As this was a test I simply displayed a message. You can see my event below. The action was a simply DisplayMessage action.
When my action was triggered I would then see the event had been triggered because I would get an alert like this.
With F5 – I loaded a CRM page in a tab. In my test I used contact but all entities behaved the same. Clicking F5 with the newly loaded tab displayed initially did nothing. But when I clicked into a field on my contact and then pressed F5 the form refreshed. But NO RefreshRequested action was triggered.
With a Refresh action – If a refresh action was used, I saw my popup and the form was not refreshed.
So the first concern with the event was therefore be to understand when it should be triggered. But when the event had been triggered what happened next?
The important thing to note was that having triggered an action in the RefreshRequested event a refresh didn’t happen. This is very useful and the behaviour I hoped to see!
If I was going to use this event in a production solution I’d watch to capture the refresh, do some actions and then finally refresh the tab. (or not!) So next I turned my attention to the final piece of refreshing the contents when required.
My first attempt failed badly! I simply added a refresh action after my display message. If you do this the refresh action will trigger another RefreshRequested event and you’ll enter an endless loop. So not what was needed!!!
I found an approach that would let me refresh the CRM form without creating an endless loop that was to fire a fresh from a RunXrmCommand action. Xrm.Page.data.refresh(); My action looked like this;
Meaning my RefreshRequested event now looked like this;
The result now was a popup saying “RefreshRequested” followed by the form actually refreshing. Perfect. J
In a previous post I explained the SessionCloseRequested event. In that I showed how you might want to validate the contents of the session and then allow the session to close or not. I mention this now as that design pattern is exactly how you’d want to use the RefreshRequested event. For example: You might want to prevent a refresh if any unsaved data existed. Or maybe you would only allow a refresh if all mandatory fields have been completed etc.
Alternatively, you could do something other than refresh the entire page. For example: You may decide to only refresh a particular subgrid rather than the complete form.
Tip: To refresh just a subgrid use a RunXrmCommand with a code like this Xrm.Page.ui.controls.get(<>).subgrid.refresh();
In summary the RefreshRequested event, when triggered, behaves as exactly as required. Allowing you to substitute the page refresh with alternative behaviour. And when required, with the help of a RunXrmCommand you can still refresh the page.
But in my test the way the event was not triggered when the user pressed F5 was a problem. It meant I couldn’t actually use it in the way I required. But hopefully that issue is specific to the version of USD I was using. (184.108.40.2066) If later versions of USD resolve this issue I will update this post accordingly.
I hope this post has been useful and that I have described the positives and negatives of this event. And also given you a few ideas on how it might be used. J
Business Applications communities