Development of a Localization Solution

If you want to bring the capabilities of the Dynamics 365 Business Central to your local market, then there are several reasons why you would want to choose Dynamics 365 Business Central:

• Easy to translate and strong base capabilities ready for localization.
• Reach more customers by showcasing your localization apps on Microsoft AppSource.
• Dynamics 365 Business Central provides a proven ERP platform and application for your localization apps, which adapts functional areas to the requirements of the local market.

Localization apps are simply apps for Dynamics 365 Business Central - learn more about getting onboarded as an app publisher here: Get Started with Building Apps.

Localization apps functionality

Localization apps contain a set of functionalities addressing local requirements that fall within one of the categories below. Make sure to split up your localization apps at minimum according to these categories:

• Regulatory requirements - local functionality that helps businesses fulfill their legal requirements, such as tax reporting, local GAAP, and other regulatory requirements.
• National standards requirement – local functionality that addresses local standards, such as banking and payment formats, address formats, or local interpretations of global standards.
• Market requirements - nice-to-have, competitive requirements – local functionality beneficial to the productivity business processes in a country and thereby adding value to business but aren't required from a regulatory perspective.

Service availability in other countries/regions

Follow this page for information about planned country and regional expansions of Dynamics 365 Business Central.

Product scope for localization apps

Apart from fulfilling the technical checklist for your app, the minimum viable product scope for localization app is:

• Local Regulatory Features.
• Tests for Local Regulatory Features.
• Upgrade code for localization apps.
• Set up data RapidStart package for the localization app.
• Translation of a localization app to local language(s) and base app if you're the first partner enabling localization for the country (Learn more about Dynamics Translation Services).
• Translation of the localization app's documentation. For more information, see Translate the Help and Translate documentation files.
• National Standard Features (local part) are recommended to be built as an app – separate from the localization app.
• Market Required and Local Competitive Features are recommended to be built as an app – separate from the localization app.
• Using .NET assemblies in your localization app will fail in the technical validation of an app. Instead, contribute to C/AL Open Library GitHub repository with requests you have for .NET.
• It's recommended to logically break down the full local functionality set, at a minimum within the above categories. This approach provides optimal flexibility for customers to choose what they really need in terms of local functionality. And it makes sure that critical pieces of local functionality don't break upgrade processes nor are upgrade heavy.
• Most customers in the local market will need most of the local regulatory features. In the category of local regulatory features there will be some features that, even though they're legally required, apply to companies of a certain size, revenue threshold etc. Such situations are opportunities to further logically breakdown localization apps into smaller focused-functionality sets.
• Consider separating localization functionality by the frequency of changes to smaller localization apps. If for example, your local feature contains one part that is stable and one part that is frequently changed based on regulation changes, make sure to keep the stable part as one app and the changing part a separate localization app. This approach ensures better test coverage, faster response to changes and fewer upgrade issues.
• Use worldwide frameworks available in Dynamics 365 Business Central (W1) when building features for, such as VAT reports, banking formats, data exchange, and others where most functionality is common to all countries/regions but there are some local rules or business formats that are extensions of global frameworks or formats. Make sure to familiarize yourself with such frameworks to reduce effort, reuse code, and properly utilize extensibility points and integration events. If you notice opportunities for improvements in such frameworks or missing extensibility points, make sure to contact us to work together in improving this.
• Consider rethinking local reports by categorizing the reports that you want to include in your localization app(s) in following categories: reports printing lists could be converted to list pages and offer more functionality using Excel add-in, reports providing insights or aggregating data could be converted to Power BI reports and dashboards, frequently customized reports (local document reports like invoices, credit memos...) could utilize Word document layouts so customer's power users can easily customize them, for all others fall back to RDLC reports
• Prepare a setup data RapidStart package for the production company and translate to local language(s).
• Consider preparing a local demo data RapidStart package for the evaluation company and translate it to local language(s).
• Prepare setup guides (wizards) for areas that are complex to set up to help users enable, discover and have a good first experience using your localization app.
• Fork the Dynamics 365 Business Central documentation from public GitHub repository. Such an approach to documentation can help when other partners or ISVs take dependency on your localization app. For more information, see Configuring the Help Experience.
• Consider converting field-based documentation to task-based documentation using tooltips and Dynamics 365 Business Central documentation GitHub repository. Rulesets can help you ensure, for example, that no fields or actions are missing tooltips.
• If your localization app(s) are extending Business Central data model with new tables and/or fields, you must set the DataClassification property correctly. Localization apps with fields having the DataClassification property set to ToBeClassified will be rejected. Read more on Classifying Data in Business Central here.
• If you're converting an existing localization (developed in C/AL) to localization apps, as described in technical checklist for your app, you'll need to set the ApplicationArea property on UI elements that you want to make visible in Business Central. To help you with this task, see Change multiple Application Area tags with PowerShell to do this in bulk.

Related information

Get Started with Building Apps
The SMB Opportunity for App Publishers
Get Started as a Reseller of Business Central Online
Countries and Translations Supported
Business Central on Microsoft training