How to Create Report in Business Central: Step-by-Step Guide
Creating reports in Microsoft Dynamics 365 Business Central is easier when you break the process into clear steps. To create a report in Business Central,...
Creating reports in Microsoft Dynamics 365 Business Central is easier when you break the process into clear steps. To create a report in Business Central, you define the dataset, design the layout, and configure user options so the right data appears in the right format. Once you know these basics, you can build reports that give your team the insights they need.
Business Central helps you pull financial summaries, track sales, and automate document generation. The main things to understand are datasets, layouts, and request pages, which ensure your reports are accurate and easy to use.
You can also extend reports, add new fields, or create different layouts for various needs. With the right approach, your reports will be useful and valuable for everyone in your Business Central environment.
Key Takeaways
Learn the steps to create accurate and usable reports
Understand how to design datasets and layouts for different needs
Discover ways to extend and manage reports for ongoing value
Understanding Business Central Reports
Reports in Microsoft Dynamics 365 Business Central are essential for delivering clear, structured information from the database. They present data in formats that support decision-making and daily operations, so users don’t have to search through raw tables.
Types of Reports in Business Central
In Business Central, there are three main report types:
Document Reports – Create formatted outputs like invoices or purchase orders, designed for printing or sending to customers and vendors.
Analytical Reports – Summarize and analyze data, such as sales trends or inventory aging, to support decisions.
Processing-Only Reports – Run logic without a printed layout, useful for batch updates or data exports.
Each type serves a different purpose. For example, document reports use Word or RDLC layouts, while processing-only reports focus on data operations and skip layouts.
Report extensions allow you to adjust existing reports without rewriting them. This saves time and keeps customizations safe during upgrades.
For more details, see Microsoft’s reports overview for Business Central.
Report Object Fundamentals
Every report in Business Central starts with a report object. This object defines the structure, data, and layout, including the dataset, layout definitions, and triggers for logic.
The Report Definition Language Client (RDLC) format is common for grid-like layouts. Word layouts are easier for business users to change without developer tools. Choose the format based on who will maintain the report and how complex the design needs to be.
The request page inside the report object lets users filter data and choose options before running the report, making it easier to use.
Keeping report objects modular allows you to reuse parts and maintain consistency across reports. This also helps with upgrades and long-term maintenance.
Role of Datasets and Data Items
The report dataset defines the data the report will use. Inside the dataset, you add data items, each linked to a database table.
For example, a sales invoice report might have a data item for the “Sales Header” table and another for the “Sales Line” table. The DataItemLink property connects these so only related records show together.
DataItemTableView is used to sort and filter data at the dataset level before it reaches the layout, which improves performance and keeps the output clean.
Include only the fields needed for the report’s purpose to help performance and simplify layout design.
Microsoft’s report design overview explains how datasets and data items work together for efficient reports.
Preparing to Create a Report
Before building a report in Business Central, make sure your tools, files, and data sources are ready. Set up a proper development environment, configure your AL project, and select the right tables or queries for accurate data.
Setting Up Your Development Environment
Start by installing Visual Studio Code with the latest AL Language extension. This provides the editor and tools needed for Business Central development.
Connect your environment to the correct Business Central sandbox. Check your credentials and ensure the sandbox matches your target version. Using mismatched versions can cause issues.
Make sure your SQL Server or cloud database is accessible if you need to check table structures. This helps confirm field names, data types, and relationships.
Configure your launch.json file in Visual Studio Code. This file sets up the connection to Business Central, including server, authentication, and tenant information. Without it, you can’t publish or test your report.
Configuring AL Files and Extensions
In your AL project, create a new .al file for the report object. Use a clear naming convention to find it easily.
Set the object type to report and assign a unique ID to avoid conflicts with other extensions.
Define the dataset section in AL, specifying the fields for the report layout. Keep the dataset minimal for better performance.
If using RDLC or Word layouts, configure and link the layout file in the AL code to provide both data and visual format.
Once the AL file is ready, package it with your extension and publish it to the sandbox for testing.
Choosing Source Tables and Query Objects
Choose the right table or query object for your report. Identify the exact data needed, such as sales orders, customer records, or inventory levels.
If the data is from a single table, reference it directly in the dataset. For more complex needs, create a query object in AL to join multiple tables. This often reduces the need for complex code.
Check table relationships in SQL Server or the Business Central table browser to avoid mismatched joins or missing fields.
Limit the dataset to only the fields you need. This keeps the report fast and responsive.
For example, a sales summary might join the Sales Header and Sales Line tables but exclude unnecessary fields for efficiency.
Designing the Report Dataset
When building a report in Business Central, define exactly what data you need, how it should be linked, and what filters will keep it accurate. The dataset is the foundation—it determines the numbers and how they connect to accounts and transactions.
Defining Data Items and Columns
Start by adding data items, which are the tables your report uses. For example, use the Customer table for account details or the G/L Entry table for transactions.
Within each data item, define columns. Columns can be table fields, variables, expressions, or text constants. Include fields like Posting Date, Account No., or Cost of Goods Sold.
Set the IncludeCaption property if you want captions for these fields. Use DataItemLink to match related fields when joining tables, such as linking Customer No. in the ledger to the customer master record.
For more details, see Microsoft’s report dataset structure.
Using Query Objects for Datasets
Sometimes it’s better to use a query object to pre-join and filter data before it reaches the report. This is useful when you need data from multiple sources, like combining General Ledger entries with Dimension values.
Declare the query as a global variable in AL. Use an Integer data item to loop through the query results. Run the query in the OnPreDataItem trigger and read each row in [OnAfterGetRecord](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/triggers-auto/reportdataitem/devenv-onaftergetrecord-reportdataitem-trigger).
This keeps the report code simple and makes maintenance easier, especially if you use the same query in multiple reports.
Applying Filters and Dimensions
Apply filters directly to data items to keep the dataset focused. For example, restrict Posting Date to the current fiscal year or limit Account Type to Income and Expense.
Include dimensions in the dataset to analyze performance by department, project, or cost center. For example, add Global Dimension 1 Code for department and Global Dimension 2 Code for region.
This lets you break down figures by business unit. In reports that combine G/L Entry and Dimension Set Entry, link them so each transaction includes its dimension values.
Applying the right filters and dimensions ensures the dataset returns precise, actionable information.
Creating and Customizing Report Layouts
When configuring reports in Business Central, select the right layout type and design it so it delivers accurate data in a clear visual format. The best approach depends on whether you need a precise design, a flexible Word template, or a data-only export.
Overview of Layout Types
In Business Central, each report can have one or more report layouts. A layout defines the visual layout and formatting of the output, while the report definition controls the data.
The main layout types include:
Layout TypeDescriptionCommon UseRDLC (RDL Layout)Client Report Definition format for pixel-perfect controlInvoices, order confirmationsWord LayoutEditable in Microsoft WordLetters, proposals**Microsoft Excel Document (Data Only)**Exports dataset without formattingData validation, analysis
Choose RDLC for precision. Word layouts are best when non-technical staff need to make changes. Excel exports are ideal when you only need the dataset.
Designing RDL Layouts
An RDL layout (also called RDLC in Business Central) lets me control positioning, fonts, and grouping. It uses the Client Report Definition format, which I edit in tools like SQL Server Report Builder.
I export the existing RDLC layout from the Custom Report Layouts page. Then I group data, set page headers and footers, and apply conditional formatting.
RDLC layouts are pixel-perfect, so I use them when I need exact alignment for printed forms. They support advanced expressions for calculated fields. However, they require more technical knowledge than Word layouts, so I only use them when necessary.
Working with Word and Excel Layouts
Word layouts let me adjust a report like editing a normal Word document. I can move tables, change fonts, and insert logos without code. This is ideal for quick branding updates or formatting changes.
When I need raw data, I export the report as a Microsoft Excel document (data only). This gives me the full dataset without formatting, which is useful for pivot tables or deeper analysis.
I use Word layouts for email templates, since Business Central supports attaching them directly to customer or vendor communications. For this, I make sure the layout type is Word-based.
For more details on creating and modifying these layouts, Microsoft provides a guide on custom report layouts in Business Central.
Configuring the Request Page and User Options
When I design reports in Business Central, I focus on how users will interact with them before execution. A well-configured request page lets users choose the right data, apply filters, and control how the report runs without code changes.
Setting Up the Request Page
I define the request page in the report object. This page appears before the report runs and lets users set options and filters. In AL, I use the requestpage block within the report definition.
Each control on the request page should have a clear purpose. I avoid clutter by only adding fields that matter for the report output.
For example, if I’m building a sales invoice report, I might include a date range selector, a customer number field, and a layout choice dropdown. Business Central allows me to design request pages so these inputs are intuitive for users.
I set default values when possible to save time for users who run the same report frequently.
Adding Filters and Parameters
Filters help limit the dataset before the report processes, which improves performance and relevance.
In the request page, filters can be tied to DataItemTableView or directly to fields in the dataset. For example, a filter on the Posting Date field ensures only transactions from the last month are included.
Parameters control how the report behaves. These might include checkboxes for “Include Archived Records” or options for grouping results.
I make sure filters are clearly labeled and logically grouped. Common filter types I use:
Filter TypeExample FieldPurposeDate RangePosting DateLimit results to a time periodLookup SelectionCustomer No.Focus on a specific customerBoolean OptionInclude DiscountsToggle inclusion of discounts
Using Request Pages for Report Execution
When a user launches a report, the request page runs first. This is where they apply filters, set parameters, and select the layout.
Business Central also supports using request pages for XMLports, but for reports, they are essential for tailoring output on demand. Users can choose the report layout directly from the request page.
I test request pages to ensure the filters affect the dataset as expected. If a filter is ignored or misapplied, it can lead to confusion and incorrect reporting.
Request pages don’t support custom action buttons in Business Central, so I design all interactions around the built-in options to keep the user experience smooth.
Extending and Managing Reports
I often adapt standard Business Central reports to meet specific requirements. This can involve adding new data, adjusting layouts, or enabling different output formats without changing the base application code.
Creating Report Extensions
When I create a report extension object, I start by identifying the base report I want to extend. In AL, I use the reportextension keyword and reference the target report name. This lets me add new fields, columns, or extra data items to the dataset.
For example, I might add a custom column from a table extension into the report dataset. I can also use triggers like OnBeforeAfterGetRecord to adjust values before they render, which is useful for calculated fields.
I check that the report’s Extensible property is set to true. Most reports have this enabled by default, but if it’s set to false, I can’t extend it. Microsoft has an overview of report extensions that outlines supported modifications.
Keeping changes additive ensures the base report remains intact and makes future updates easier.
Managing Multiple Report Layouts
Sometimes I need to provide different layouts for the same report. Business Central supports multiple report layouts, which I define in the report extension. Each layout can be in Word, RDLC, or Excel format.
I add new layouts in the rendering section of the extension. Once deployed, these layouts appear in the Report Layouts page, where I can set a new default.
Layouts from an extension are not applied automatically; I must manually assign them to the report. This lets me offer, for example, an internal analysis layout in Excel and a customer-facing layout in Word for the same dataset.
This approach helps different teams choose the format that works best for their needs.
Publishing and Testing Reports
After building the extension in Visual Studio Code, I publish it to my Business Central environment using the AL: Publish command.
Once published, I run the report to verify that the new fields and layouts work as expected. I often export the dataset to Excel in “data only” mode to confirm the correct values are present before checking the formatted output.
I also test with different UsageCategory settings to ensure the report is visible in the right navigation areas. For example, setting UsageCategory = Administration helps system admins find it easily.
Frequently Asked Questions
When I work with reports in Business Central, I focus on clear data modeling, efficient layout design, and using the right tools for the job. I can adapt standard reports, create custom ones, and ensure they fit operational and compliance needs.
What steps are involved in customizing report layouts in Dynamics 365 Business Central?
I start by identifying the dataset that the report will use. Then I choose the layout type—Word, Excel, or RDL—based on the audience and purpose.
Next, I adjust the layout in the chosen editor, making sure the data fields fit business needs. I test the output for accuracy before publishing.
Can you explain how to use the Report Builder for creating reports in Business Central?
When I use Report Builder, I connect to the dataset defined in Business Central. I design the structure by adding tables, charts, and grouping as needed.
This tool is especially useful for creating RDL layouts, which allow advanced formatting and logic. Once complete, I upload the layout back into Business Central.
What are the best practices for utilizing report triggers to enhance reporting in Business Central?
I use report triggers to control actions before and after data processing. For example, the OnPreDataItem trigger lets me set filters, while OnAfterGetRecord is ideal for calculating values on the fly.
Keeping trigger logic simple helps maintain performance and makes the report easier to maintain.
How can I extend a standard report in Business Central to fit specific business needs?
I create a Report Extension object when I need to add fields, data items, or layouts to an existing report. This avoids modifying the base report directly and keeps upgrades smooth.
I test the extended report with real data to confirm it meets the new requirements.
Could you guide me through the process of setting up report selections for different scenarios in Business Central?
I open the Report Selections page to assign specific reports to different document types or processes. For example, I can set one invoice layout for sales and another for service documents.
This setup ensures the right report runs automatically in the correct context.
What tools and techniques are recommended for efficient report development within Business Central?
I use AL code in Visual Studio Code to create and modify reports. The built-in request page functionality helps users set filters and options.
For layouts, I select the editor based on the task: Word for documents, Excel for analysis, and RDL for complex designs.
