Dynamics 365 Customer Service

There should be more felxibility when creating a a recurring series in a work hour calendar, there should be options similar to Outlook:

• "Every X weeks"
• "Monthly - First x-day of the month"
• "Monthly - xth day of the month"

It would be great if Microsoft can build a solution to host CRM inside Twilio iframe

Current limit for a call including customer wait time is 2 hours. At the 2 hour mark the call will just disconnect. Increasing this limit would help avoid some unnecessary disconnects when hold times are longer.

Hello Team,

We want to create an idea to remove the legacy app from D 365.

Please assist.

When using MS Teams for internal collaboration currently this does not impact the status in omnichannel.

In case an agent receives a Teams call it might be relevant to also update the agent status in omnichannel.

There are already other contact center solutions in the market offering this functionality with MS Teams. Would be logical that this is also supporter in the Microsoft ecosystem.

Just like in Microsoft teams it would be useful for an agent to set a secondary ringer device.

If an agent leaves the desk for a moment the call is only ringing in the headphone. Would be handy to also let it ring on the computer / screen.

Custom Messaging APIs might not be the most suitable category, but I just haven't found a better option. We have performance problems with Dataverse plugins in general, so it doesn't fit into any category.

Some of our plugins fail with such an error (Operation not allowed as plugin execution exceeded maximum allowed time), which makes us think that there is some undocumented limitation about how many times/how frequently can a certain plugin be executed. It is definitely NOT the 2-minute execution timeout limit (System.TimeoutException: Couldn’t complete execution of the xxxx plug-in within the 2-minute limit), which we are well aware of.

Our plugin does nothing time-consuming, plugintracelog.performanceexecutionduration constantly stays below 100 msecs. We haven't experienced it in most environments, but have a single customer who is running a contact centre with ~700 agents and several thousand phone calls get created each day. We have a few plugins hooked up for - amongst others - the create message of phonecall and connection entities, this is where (so far) this problem came up.

As a workaround, we ported the affected plugins to a CodeActivity with no other code changes and added to a synchronous workflow, triggered on the same event. There is no error anymore, so the problem is definitely not in the code (these are rather simple plugins).

This problem came up during the daily operation of this high-volume customer, but we could reproduce it when migrating large amount of data, with the plugins enabled.

I had a conversation with support, they suggested to submit the problem here.

So there should either be

• a clear documentation on performance limitations of plugins, and/or
• these limitations should be revised because are causing problems in case of high-volume scenarios.

We do understand that there has to be a limit on how many times a plugin can be executed, but it should be somehow tied to the number of user licenses, to avoid problems in high-volume environments.

When agent accepts a voice call, the presence should change to a new status of “In a Call” rather than the current “Do not disturb” status.

It’s hard for supervisors to differentiate whether the agent is in an actual call or if the agent has manually selected the “Do not disturb”status.

Agents should not be able to manually select the “In a Call” status.

Problem: the Duration value could be changed wrongly without any warning or control when the user type text in the Duration field by mistake (very particular scenario). Then user leaves the Form without realizing the duration was updated by the system to something different

Here 3 scenarios where I change intentionally the Duration field (initially as "2 Hours") with some text (in the middle, next to the number of hours, next to the label “hours”), and it seems this problem happens in one specific scenario

1. Duration field with text in middle --> the Duration is corrected back to 2 hours value

2. Duration field with text in next to the number of hours  --> the Duration is corrected back to 2 hours value

3. Duration field with text next to the label “hours” --> the Duration is wrongly changed to 2 minutes value

Currently, in the default environment, the role of environment creator is not authorized to delete model-driven apps. This is because only the Administrator role is configured to have delete privileges. However, since environment creators often create and use model-driven apps, it is desirable to give them delete privileges.

Since environment creators often create and use model-driven applications, it is desirable to allow them to delete them when necessary.

Also, by granting appropriate privileges outside of the administrator role, the burden on the administrator can be reduced and the environment creator can work freely.

For these reasons, we strongly request that the environment creator role be granted the authority to delete model-driven applications.