FDDs speak the application language and terminology, so business analysts writing FDDs must understand the D365FO application and functionality. A lack of product knowledge and understanding can keep the document at a high level, pushing the design aspects to the developers, which deviates from the purpose of the document.

Always ensure that all of the key decisions made during the design time are recorded in the key decision log and signed off by the project team. Recommended areas where key decisions are mostly taken are as follows:

• Financials
• Inventory costing
• Adjustments
• Integrations
• Reporting

Also, all assumptions should be documented and validated with the concerned stakeholders to ensure a solution built to purpose.

Microsoft Dynamics Sure Step provides good templates to write FDDs. Create your own version with the sections relevant to your project and have the team follow the template.

Always have one or many requirements in the Requirements Traceability Matrix (RTM) corresponding to the FDD. A RTM is a foundational element in ERP implementations, as it ensures consistent delivery against contract and business requirements.

Another important aspect to consider before starting to write the functional design document is to know the feasibility of the solution. With the release of D365FO version 8.0 (April 2018), customizations are possible through extensions only. The extension is a development model where the developer can utilize events and hooks within the application code to include additional functionalities without impacting the Microsoft code. What this means from a solution design perspective is that, unlike earlier versions, there will be a scenario when a requirement cannot be customized.

To make sure that your custom solution is feasible, consider the following points:

• There could be a customization requirement that it may not be possible to develop through extensions.
• If there are no options available in the product to extend the requested functionality, find a workaround or take Microsoft feedback. Ultimately, if it's not feasible, say no to the customer. 
• If you think your requirement is common, suggest it to Microsoft using the idea portal; it might become a part of the core product in future releases.
• Also, check the Microsoft roadmap for upcoming features and to see if those can fill the gap.

Finally, let's discuss some common dos and don'ts you should consider during the design phase.