Slow forms are usually caused by overly complex queries with too many joins, customisations that trigger unnecessary server calls on form load, missing database indexes on frequently filtered fields, or users running large unfiltered queries that return thousands of rows. Start with the D365 Performance Trace Parser to identify which queries are taking the most time. Customisation-heavy environments need their X++ code reviewed for N+1 query patterns and unnecessary full-table reads — these are the most common performance killers introduced during implementation.

Use the Batch job history and the System diagnostics workspace to identify which jobs are taking longest and whether they are running single-threaded when they could be parallelised. Many standard D365 batch jobs support multi-threading via batch bundle and task configuration — enable this for heavy jobs like MRP, cost rollup and statement posting. Also check for batch jobs that are competing for the same database resources: serialised jobs that should run in sequence, not concurrently, are a common configuration problem. Batch server capacity — CPU and memory — needs to scale with transaction volume.

Customisations are the single biggest source of D365 performance problems in production. The most damaging patterns are: queries without WHERE clauses on large tables, display methods called on every row in a grid, event handlers that trigger synchronous external calls, and unoptimised X++ loops processing large datasets row by row. Establish performance standards during development — mandatory code review for any data access pattern, performance testing as part of every deployment gate, and a query budget per page load. Performance problems introduced at go-live are exponentially harder to fix under live conditions.