powerobjects: How to Prevent USD from Closing a Session with Unsaved Changes
One great feature of Unified Service Desk (USD) is its ability to manage sessions during customer service interactions. This functionality allows customer service reps to unify information and applications for each customer in separate sessions, which in turn helps improve performance and service.
For example, a company might use Microsoft Dynamics 365 to handle their contact, policy, and case information. However, they might use completely different applications for billing and event registration. Imagine the number of application windows that a customer rep would need to have open in order to help a single customer! Now multiply that if the same rep must multitask and help numerous customers at the same time. It would be a nightmare for the rep to navigate through different applications just to find the correct customer information and perform their job.
USD resolves this issue and helps improve resolution time by creating a session for each customer so that reps can simply select the correct session and retrieve the correct customer’s information with a single click.
However, with this great advantage comes an issue that can have a large impact on data if it is not handled properly. Out of the box, if you close a session in USD, it does not check to see if there are any applications with unsaved changes. Upon closing a session, USD closes all applications under that session without saving any data. If customer reps are not careful, they might lose a lot of important information about their customers and they will be unable to recover that information.
To prevent this, we can use a combination of USD actions and events to check if one or more applications have unsaved changes. If there aren’t any changes that need saving, we can program USD to close the session automatically. If there are one or more unsaved applications, we can inform the user about it and let them decide whether to cancel the closing of the session or to end the session disregarding the unsaved changes. We can perform this on any application that is able to check for unsaved changes and communicate back to USD using USD events. For ease of demonstration, this blog will show you how to do so for two Dynamics 365 pages.
For the demo, let’s pretend that we have to perform the check on the Case page and the Contact page for the customer. The part that makes this issue trickier is that at any given time both pages may be open or only one might be open. We must somehow handle both scenarios. To resolve this, we will utilize Dynamics 365 CRM’s native XRM “getIsDirty” function to check if the pages are dirty and then trigger USD events to inform USD with the result so that USD can take appropriate next actions.
Let’s look at the flow we will be utilizing to check if the pages are dirty:
Let’s begin by hijacking the ‘X’ close button next to the session tabs. To do so, we need to open the SessionCloseRequested event on the Session Tabs hosted control and associate some actions to this control.
Create the following actions on the “SessionCloseRequested” event:
Notice the conditions on these actions. The first one checks if the Contact page is dirty, but only if Contact Page is open in the session. If contact page is dirty, it prompts the user whether or not to close the session without closing the session. If contact page is not dirty, it triggers the “CheckIfCaseDirtyEvent” event that we will configure in a bit.
The second action in the list checks if the Case page is dirty, if the Contact Page is closed and the Case Page is open or if “CheckCaseIsDirtyTriggeredFromEvent” parameter is true (which we will use below). If the case page is dirty, it prompts the user with the same notification as the contact page. If it is not dirty, it calls the “CloseSessionNoDirtyPagesEvent” event (more on this below).
The third action is triggered if both the contact page and case page is closed or if “CloseSessionRequestedFromEvent” parameter is true (the latter condition will be used below). This action closes the active session.
By this time, the “SessionCloseRequested” event should have these actions associated to it:
The first two actions above trigger USD events using the “windows.open” function. Note that even though the two actions might trigger an event with the same name, we will need to create two separate event records and associate it both Contact and Case page. Now, let’s add these events and associate previously created actions to USD as shown below:
Now, let’s try closing a session with unsaved changes on either contact page or case page:
As you can see, we have successfully created a notification mechanism to make customer reps aware if there are unsaved changes within a session. You can use this same technique in as many CRM pages as you want. You can also do the same with other external applications as long as you have control over the code for those applications and can check: 1. If the application has dirty fields that needs saving and 2. If it can trigger USD events.
We hope this helped you save some data! For more troubleshooting tips and tricks, be sure to subscribe to our blog!
Happy USD’ing and Dynamics 365’ing!
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|powerobjects: Why Projects Fail and How to Prevent It||Blog bot||Dynamics CRM: Blogs||0||25.04.2018 00:21|
|powerobjects: How to Configure a Point of Sale in D365 for Retail in a Day||Blog bot||Dynamics CRM: Blogs||0||17.03.2018 02:19|
|powerobjects: How to Export a Theme from One Dynamics 365 Org to Another||Blog bot||Dynamics CRM: Blogs||0||16.12.2017 00:13|
|atinkerersnotebook: Walkthrough & Tutorial Summary||Blog bot||DAX Blogs||1||09.09.2013 09:11|
|wiki.dynamicsbook: Changes Made in Navision Attain 3.60||Blog bot||Dynamics CRM: Blogs||0||02.09.2008 13:23|
|Опции темы||Поиск в этой теме|