Firstly note that this is going to be iterative process.
I would probably start with a trace rather than directly creating the index based on the SQL Server recommendation.
Run the specific AX/D365 operation that is showing the performance issue and capture the SQL generated by it. From the trace, identify the query that is taking the most time or doing a high number of reads, and then check whether it is related to the table/columns mentioned in the missing-index recommendation.
I would then take that query and run it in SSMS against a representative non-production database with the Actual Execution Plan enabled. Capture the baseline metrics such as logical reads, CPU time, elapsed time, and whether SQL Server is doing a scan or seek.
After that, create the proposed index in the test environment and run the same query/AX process again. Compare the execution plan and performance before and after the index.
So essentially:
Trace AX transaction → identify expensive SQL query → review execution plan → establish baseline → test proposed index → compare results.
I would not implement a missing-index recommendation just because SQL Server is suggesting it. The recommendation is a good starting point, but you also need to consider existing/overlapping indexes, index maintenance and write overhead, and whether the index actually benefits the specific AX transaction you're trying to improve.
That gives you a much more reliable answer than simply saying "SQL Server recommends this index, so we should create it."
