Docs Structure

A recommended structure for your app's documentation, with sections that each support one stage of your customer's work with the app.

Microsoft Dynamics 365 Business Central's own documentation is organized into a set of core areas. Business Central users already know that structure. That's why we recommend organizing your app's documentation the same way.

The areas below show the recommended full scope of documentation for a Business Central app. Together with you, we choose which areas to cover and where to focus first. We base that choice on what matters most for your app and your customers.

New and planned

Every update to your app changes what your customers can do. They need to know about it without searching a changelog or contacting your support team. This section can track each release by version number, grouped by year, with a page for each release that explains what changed. Customers typically check it before they upgrade, and when something behaves differently than it used to.

It's also a good place to list the versions of your app you support and the Business Central versions each one works with. It can show what's coming next: planned features with their expected release dates, and features in progress that don't have a date yet. If some capabilities are in preview, this is where you can state which ones, and which are generally available. That way, customers know what they can rely on in production.

Get started

Getting started rarely means the same steps for every customer. Someone installing your app online needs different instructions than someone running it on-premises. Where that applies, this section can branch by deployment type, so customers land on the instructions for their situation. The quickstart, key concepts, and FAQ that apply to everyone can sit next to them.

We recommend opening the section with an overview of what your app does, written for someone who's still deciding. This is also where prospects can find out how to start and extend a free trial, what a subscription includes and costs, and how to buy through a reseller or partner. For new customers, the section can offer learning material: training, videos, walkthroughs, and demo data to practice on. It might also hold the glossary and a comparison with standard Business Central, and end with the FAQ, links to knowledge base resources, and contact details for help and support.

Business functionality

This is where most of your documentation usually lives. It works best when it doesn't read as a flat list of features. Instead, we recommend organizing it around how your customers work: by business process, by module, or by the core entities your app manages. Each area combines conceptual articles that explain how something works with step-by-step procedures. A design details page serves customers who want to understand how the app works internally, not just which actions to choose.

Each area starts with an overview and walkthroughs of common business scenarios. Setup and configuration articles explain the initial setup and the options that matter, with recommendations. Process articles describe complete workflows, broken down into procedures for each task, and operational guides cover the daily work. If your customers work in different industries, this section is also the place to show how each industry uses the app, with typical use cases.

Integrations

If your app exchanges data with other systems, such as webshops, payment providers, or external services, this is where customers can find the details: how the connection works and how to keep it running.

We recommend a separate set of articles for each integration. They can explain what the connection does and which data moves in which direction. They can show how to set it up, from the first step to a successful test. Where they matter, platform limits and exceptions belong here too. Troubleshooting content can help customers find which side of the connection failed and what to do about it. That way, a broken synchronization doesn't have to become a support ticket.

Security, privacy, and compliance

How much belongs here depends on what your app does. An app that processes financial data, personal data, or other regulated information should explain how it handles that data and name the compliance standards that apply. An app that doesn't touch sensitive data might need only a short page that confirms it. Prospects, and the partners who implement your app, often check this section before they commit.

Where it applies, the section can describe how your app protects data and which security practices customers should follow. It can also explain which features control access and how personal data is handled. Finally, it can list the certifications and regulations your app complies with, and the service commitments you make to customers.

Development and administration

Some apps run continuously inside Business Central, by connecting to other systems or by processing data in the background. For these apps, this section is where your customer's IT team can turn when something needs attention. It can show how to monitor the app, what to check first when something breaks, and how to dig deeper when the first checklist doesn't solve the problem. It's also the place for the technical reference an administrator or developer needs to extend or customize your app safely.

Here, you can explain how to install and upgrade the app, online and on-premises, and list the system requirements and the upgrade and migration paths between versions. For developers, the section can document the APIs, the events your app publishes, and the guidelines for customizing it. For administrators, it can explain the permission sets and security roles, the licensing model, and advanced troubleshooting steps.

This structure follows the conventions Microsoft uses for Business Central documentation, so your customers already know how to find their way around it.