Comments
Adding more details for this topic.Background –The static segment had several limitations; we initially had a cap of around 100 contacts. This seems to have changed now but due to this constraint and based on the recommendation, we created a separate record that would eventually connect to a dynamic segment. Issue/Challenge –Our main challenge today is the complexity around segment refresh times. Different types of segment refreshes at different intervals anywhere from 30 minutes to 24 hours depending on how the segments were created. For users this becomes difficult to manage the logic behind the refresh time as it is not intuitive. So, it's hard to remember which condition led to which refresh delay. This becomes even more tedious when users want to build a segment with specific rules but only need to use it once. We usually plan and build journeys several days or even weeks in advance. And another thing is where we use our static segment that we needed to be created for the automation with dynamic segments and then we upload contacts to it. Here the problem is that the journey start date becomes unreliable and hence the emails are not sent. Possible solution - Ability to refresh the segment manually on UI.
Something we're using as a "workaround" is piping API calls you want to see the contents of through Logic Apps on Azure. Allows detailed logging, additional processing and you can have a different authentication scheme and url scheme using APIM.Not a fun sell of course and has its own issues.
Our organization relies heavily on FetchXML-based SSRS paginated reports for Dynamics 365 Customer Engagement. These reports are essential for compliance, operational reporting, and integration with existing workflows.Currently, the Report Authoring Extension only supports Visual Studio 2019 and earlier. Visual Studio 2022 introduced a 64-bit architecture, and the lack of support for this extension creates significant challenges:Increased operational risk from outdated tools.Higher costs for licensing alternatives.Delays in delivering critical reports to business stakeholders.
In additional, I think some cross dimension value settlements won't be important for some financial dimensions, so to refine it further, it would be good in the year end config, to be able to define by financial dimensions, those which you do not want to allow cross dimension value settlement.
This is a real issue when dealing with purchase orders with long lead-times that will have ETAs changed likely more than once due to external factors such as transshipment delays, conflicts impacting regular shipping routes, weather, etc. It shouldn't be a problem to be able to change dates and quantities simply because a Quality Order is still on open status, which by the way is generated once a Receipts List is created. Receipts List can be created well in advance depending on each business particular ways of working and, again, shouldn't be an impediment to enable PO dates to be changed.