-
Option to select Monday - Friday of a week as the default time frame in D365 dashboards
Suggested by Bijay Deb Roy – New – 3 Comments
Today the D365 customer service dashboard shows 'ThisWeek' time frame which shows data for all the 7days of this week. There is a need to show the data based on working days (Monday to Friday) as the default filter. This makes it necessary to set custom time frame every time user opens the dashboards. Could you please provide option to select workdays timeframe option in the dashboards.
-
Ring all functionality
Suggested by Peter Koeslag – New – 2 Comments
Using the working distribution methods, please add a "ring all" functionality.
In case of emergency the workitem (call) will be offered to all available agents at the same time. The first agent who will accept this call can handle this one.
Special for Contactcenters with high priority workitems (like emergency, notifying of a death).
The "ring all" is a basic feature in all kind of phone systems...
-
Hearing a beep as a customer service agent that receives the phonecall to indicate the connection is completed and the call is starting
Suggested by Annemiek Schothorst – New – 4 Comments
To improve the efficiency and responsiveness of customer service agents, I propose the implementation of an audible beep signal that alerts agents when a phone call connection is successfully completed and the call is about to begin. This feature will enhance the omnichannel customer service experience by ensuring agents are immediately aware of incoming calls, reducing initial response times and improving overall customer satisfaction.
Benefits:
- Improved Agent Readiness:
- Agents will be more prepared and alert, leading to smoother call openings and more professional interactions.
- Reduced Customer Wait Time:
- Immediate awareness of call connection reduces awkward silences and unnecessary wait times for customers.
- Enhanced Customer Experience:
- A prompt and professional start to the conversation sets a positive tone for the entire interaction.
- Increased Efficiency:
- Streamlining the call connection process can lead to quicker issue resolution and better overall efficiency in handling customer inquiries.
-
Custom Sorting for Presence Statuses
Suggested by Michael Jahn – New – 0 Comments
We are currently using base and custom presence statuses in our system. However, we have identified a need to reorder these statuses according to a custom sequence rather than the default alphabetical order.
For example, we would like to arrange the statuses in the following order:
- Teamlead
- Buddy-work
- Available
- Chat
- Busy
- Busy-DND
- Away
- Offline
Unfortunately, the system currently enforces alphabetical sorting, and base presences cannot be edited, which limits our ability to implement a custom order.
We believe that allowing custom sorting for presence statuses would greatly improve user experience. We kindly request the addition of functionality that enables the manual reordering of presence statuses.
-
Ability to know whether the record registered in the "Cases" entity has been read or unread
Suggested by Ryoko Matsumoto – New – 0 Comments
Currently, there is no functionality to know whether a record registered in the "Cases" entity has been read or unread.
Adding this functionality will improve convenience for users.
-
CRM internal header is containing the period "." which is not following HTTP header standard
Suggested by System Administrator – New – 0 Comments
CRM internal header is containing period as below which is not following the HTTP header standard
"mscrm.returnnotifications"="true"
HTTP Headers defined by RFC2616, RFC2822, RFC7230 advise against the use of non-standard characters such as the period below:
Sec-Fetch-Site – Acceptable HTTP header delimiter usage ‘-‘.
accept – Acceptable HTTP header non-delimiter usage.
We should fix this one (maybe replace the period by hyphen for internal CRM header)
-
Agent presence localized labels
Suggested by Tom Ten Kate – New – 0 Comments
The Agent status presence - in customer service workspace currently only has labels for the default localization of the system.
When the system has additional languagues, the presence status records do not have a localized label for the user language.
Please add localized labels for agent presence status.
-
Enable deletion of e-mail attachments of incoming e-mail from new attachment grid
Suggested by Mila Morelissen – New – 0 Comments
To enhance data privacy and compliance with GDPR regulations, it is essential to (re-)enable the deletion of personal or sensitive attachments directly from the new attachment grid in incoming emails. By allowing direct deletion of attachments within the grid, we can streamline the process, improve user experience, and ensure that only necessary data is stored. It is an improvement that we can use the preview function but I am disappointed with the decision to remove the delete functionality. It was very useful, and its absence has negatively impacted our workflow.
-
Application Tab Template Configuration for Session
Suggested by Jason Müller – New – 0 Comments
Within a Mutli-Session App the Application Tab Template should have the possibility to have a Parameter to update the Tabs.
The Paramater should reload the Tab in the Multi-Session on save or on change of the in the Application Tab Template defined lookup of the entity record.
-
Case Origin Logic in Quick Create Case Form
Suggested by Kristine Risberg – New – 0 Comments
Improvement Suggestion for Case Origin Logic in Quick Create Case Form
When creating a new case from an active conversation using the +New Case button, I am directed to the Quick Create Case form. In this form, certain fields such as the related Customer, Case Owner, Case Priority, and Case Origin are pre-populated with values derived from the active conversation. However, the Case Origin field is automatically set to "Web" regardless of the channel used for the conversation (e.g., live chat, voice call, SMS).
If no default value is set in Entity Meta Data for Case Type Incident when getting data from Channel Integration Framework, the system assigns the value of 'caseorigincode' attribute as Web. This is set irrespective of channel type on the live work item. This requires manual, an unnecessary, adjustment by the agent every time a case is created from a conversation.
Suggested Solution:
A permanent and reliable solution would be to ensure that the Case Origin field dynamically reflects the channel type at the time of case creation, rather than defaulting to "Web." While the current workaround (e.g., using a post-operation plugin on the Retrieve or RetrieveMultiple messages to modify the returned entity) can address this issue, a built-in solution that automatically matches the Case Origin to the channel type would significantly improve the user experience and eliminate the need for custom development.
Benefit:
This improvement would ensure better consistency between the communication channel and the case metadata, reducing the need for manual adjustments and offering a more seamless case creation process.