Comments
Now we have year 2026 and it is still not solved. We have the same problem. Microsoft ignoring the needs of the customers. Microsoft does not provide us the possibility to maintain the database. Database is growing with data that is not needed any more. This costs the customers money (since we need more capacity). It makes D365 F&O slow (bigger database = slower)It makes maintenance slower (e.g. database copy)
We hit this same issue constantly - hundreds of Shopify exchanges/returns each requiring the same manual unlink → resolve conflict → recreate invoice steps. It's a huge time sink and error risk at our volume. We're actually considering a custom workaround just to avoid this, but would much rather see an automated/bulk conflict-resolution option added to the standard connector. Please prioritize this.
We've run into this exact issue while reconciling applications across our dev, UAT, and production environments - the same first-party app sometimes shows up under a completely different name depending on which package version is installed (e.g., "App profile manager" vs "Appprofilemanager"). It makes it really hard to confidently confirm we're aligned across environments without manually cross-checking or opening a support ticket. A stable identifier alongside the display name, plus a clear in-product indicator when a name difference is just due to a package version, would go a long way. Even just knowing an update is available and what it changes would help us plan rollouts with more confidence. Would love to see this prioritized since it adds real administrative overhead every time we do an environment comparison.
The current configuration is global per entity and applies the same task count to every execution above a single threshold, regardless of the actual volume or legal entity.For example, with a threshold of 200 records and a task count of 8:An import of 20,000 products creates 8 tasks of roughly 2,500 records each, where parallel processing is likely beneficial.An import of 2,000 products also creates 8 tasks, now with only around 250 records each. This consumes the same batch/AOS capacity while potentially adding more scheduling and partitioning overhead than performance benefit.A more adaptive design could support either:Multiple volume bands per entity, such as 2 tasks above 400 records, 4 tasks above 1,500, and 8 tasks above 10,000; orA target records-per-task value combined with a maximum task count.This would allow DMF to calculate an appropriate degree of parallelism for each execution rather than treating every import above the threshold identically