Module Structure

Customer-specific extensions in Dynamics 365 FO should follow a modular structure inspired by Microsoft's conventions. This approach ensures logical organization, globally unique module names, and self-documenting naming practices.

A typical project consists of 5–10 modules, balancing clarity and maintainability. Key naming guidelines:

• Start with a customer identifier.
• Clearly describe the business area or functionality.
• Include technical or process-related details as necessary.

Avoid Over-Categorization

Avoid splitting minor functionalities into too many modules. For example, combine smaller features like individual reports into a single module, such as CustomerReports.

Categorize by Business Processes

Organize modules by business processes, mirroring Microsoft's structure (e.g., AccountsPayable, GeneralLedger, WarehouseOrders).

Business Process Examples

• Finance: CustomerAccountsPayable, CustomerGeneralLedger
• Supply Chain: CustomerWarehouseManagement, CustomerInventoryManagement
• Human Resources: CustomerPersonnelManagement
• Projects: CustomerProjectManagement

Categorize by Technical Extensions

For technical functionalities like integrations or reporting, use dedicated categories.

Technical Extension Examples

• Integrations: CustomerIntegrationShopify, CustomerIntegrationMulesoft, CustomerIntegrationKlarna
• Reports: CustomerFinancialReports