Comments
I started working on AX 2.5 in 2002. In the last 20+ years in numerous past AX implementation projects, I was the witness of performance issues caused by parameter placeholders. Some of the most problematic queries are the ones launched by InventSum::findSum, InventSum::findSumQty and BOMVersion::selectBomVersion methods. There are scenarios where the number of records can be unevenly distributed in BOMVersion, InventSum and InventDim.For example when product configurator is heavily used, it can lead to some items being linked to millions of records because of high number of configured variants. Compared to a few hundred/thousand records for items not using configuration dimension.Another example is when warehouse management is set up using heavyweight sites/warehouses combined to some other lightweight sites/warehouses linked to small subsidiaries or secondary stocking locations. Again, million of records can be found in InventSum and InventDim for one specific main warehouse. Compared to a few thousand (or less) records linked to smaller warehouses.When data is unevenly distributed, native queries over BOMVersion/InventSum/InventDim are causing intermittent performance issues and/or fluctuations. A same query can be attached to multiple execution plans when doing analysis in SQL Server Management Studio. Average query execution time can vary from 50 ms (or below) but sometimes up to more than 500 ms.Currently, this is not possible to use CoC (chain of command) to replace the native logic in above methods but also in a lot of other place across the entire application.There is a 'Literals' property on extended data types. But as of application version 10.0.44, modifying the value of this property using edt extension doesn't seems to have any effect.
Also posted by another user/customer here https://experience.dynamics.com/ideas/idea/?ideaid=caa0cf58-5beb-ee11-a73e-002248504629, please upvote both submissions. It's a highly requested feature by clients to avoid having to manipulate usage of holiday function and holiday message as to not mess up the running standard out of office message.
Seems redundant to control this on queue level if all underlying queues in the voice channel are closed, if calendar is applied as channel operating hours. Currently there is no overflow handling on channel level, although channel can be closed due to out of office hours. So request is valid, although it should be on corresponding channel, and not workstream, level.
100% agreed. The system-initiated outbound callback call is not currently shown as an active interaction in the real-time dashboards. This results in an incomplete picture of real-time voice load and agent engagement, especially for organizations with high callback volumes. When callbacks represent a significant share of inbound demand, this gap makes it difficult to monitor actual active voice traffic in real time, accurately assess agent occupancy and workload and maintain service levels during peak periods. It would be great to see a roadmap update or planned enhancement to include callback calls in Omnichannel real-time analytics.