Ian Podmore Business Process Leader

Mobile users working with offline are unable to delete a Work Order Service or Work Order Product that they have added in error.

They only have the option to set the quantity to 0.

It would be useful for the mobile user working offline to be able to delete a record.

The SLA instances calculate the Active Duration of an SLA associated to a Case.

The Active Duration calculation takes into account the Working Hours of the calendar associated to the SLA Item which is very important. It is however restricted to only calculate until the planned SLA expiry which makes the data partially incorrect (i.e. when the SLA was not met within the target time)

A field is needed in the Case entity that sums the Active Hours for Case resolution regardless of whether the SLA target was met or not. This will allow easy reporting and management of actual Case resolution duration.

A lesser solution would be to simply allow the SLA Instance to continue to calculate the Active Duration until the SLA success condition(s) were met. The current Active Duration when the SLA is not met is simply a copy of the SLA Item data so has no additional value.

The scenario is that an Agreement is created and activated by a user that subsequently leaves the company.

The Owner of the System jobs that are then waiting for say Agreement expiry or a Booking Date to create a Work Order does then not have the system permissions to run that System Job so the Background Process / System Job does not run.

Suggestion is that when the Agreement Owner is changed, any background System Jobs for the Agreement are cancelled and new ones created with the User set to the new Owner of the Agreement.

Further suggestion would be that when the re-assign records feature is used from a User record, that any System Jobs owned by that user will be cancelled and recreated with the new user.

In Outlook when you 'reply all' the sender does not get the email they sent in their Inbox.

In D365 Customer Service when you use Reply All to an Email in the Timeline of a Case, the sent email will appear 2 times, once as the Sent email, then again as a received email.

The Reply All should not include the sending email account/queue in the To or cc of the email so that it works in the same simple way that Outlook does.

Users currently have to delete the sender queues/contacts from the email that is created from reply all to avoid getting their sent email back as a received email.

The standard tab that is opened from the Home session of the workspace is the Dashboard.

A dashboard can be configured with multiple views that users need for their day to day work. The space to view the lists/Views in a dashboard is limited.

It would be far easier for users to have the defined Views opening as default tabs on their Home session to avoid having to manually add them every time they start using the system. This would be in the same way that additional tabs can be configured to open when a new Case session is started.

It is much easier for a user to work with a complete screen view of their Cases etc rather than a small slice of the screen when using a dashboard that also needs a user to scroll up and down the dashboard.

In the Customer Service app a user can ask CoPilot questions that relate to Knowledge Base Article content and receive an AI reply based upon the Knowledge Base Article content in the system.

In the Field Service App the CoPilot functionality appears to be limited to counting records and similar basic actions except for Work Order summaries.

Technicians in Field Service would massively benefit from being able to ask questions and have AI responses from Knowledge Base Articles to assist them in resolving issues on machines.

When an Email is received and the To contains both a User and a Queue Mailbox, the system by default uses the Users mailbox to handle the Email.

When D365 is used for Sales and Customer Service, the company will usually create Queues associated to Mailboxes to handle customer enquiries including Purchase Orders to the company. The Users mailboxes will be used by Sales personnel to track their emails into D365 for Contacts in D365.

The members of the Queue will handle the Cases created by the ARC rules associated to the Queue to fulfill the customers requests.

When the Email from the customer contains an email address for a User Mailbox, such as a sales person, and a Queue Mailbox for Customer Service, the default system behavior is to connect the incoming Email to the User Mailbox. The Customer Service queue members are therefore unaware that there is a customer Email with a request for action.

The Mailbox priority would be better to be configurable to that companies that use D365 for multiple purposes can ensure that Emails are routed first and foremost to the Queue Mailboxes.

There are too many sales user mailboxes to configure rules on each of them to prevent Emails being taken by the User Mailbox in this scenario.

It is not possible to have the same Email creating multiple Cases as some customers email multiple Queues with one request, which should only be actioned by one team, as it would lead to duplicate effort for a single request.