11 minutes

Using configuration packages correctly in Business Central

If you work with Microsoft Dynamics 365 Business Central, you are probably familiar with this situation:
Item data needs to be provided for a new project, a test system, or a data maintenance operation. Several people need to supply content, some of them without direct access to Business Central. This quickly leads to Excel being used, in the hope that the data will later be transferred back to the system in a clean format.

In most cases, however, these hopes remain unfulfilled. In practice, this often means manual rework, import errors, or inconsistent master data for you. This is exactly where configuration packages come into play. They are one of the central tools in Business Central for exporting, editing, and reimporting data in a structured manner—in a controlled and reproducible way.


Why configuration packages are important

Configuration packages are used wherever master data cannot or should not be maintained directly in the system. Typical examples are articles, units, or posting groups that must first be prepared or revised externally.
Instead of entering data manually, configuration packages enable a clearly defined process:
Data is exported in a targeted manner, processed offline, and then imported again. This reduces errors, saves time, and ensures that the data structure of Business Central is maintained.


What is a configuration package?

In Business Central, a configuration package is a collection of tables and fields that are used for data export or import. In addition, filters can be defined to control the amount of data in a targeted manner. A configuration package thus determines which tables are affected, which fields from these tables are used, and which data records may be exported or imported. On this basis, you can export data to Excel, edit it there, and then securely import it back into Business Central.
Configuration packages are also ideal as templates, for example, when process participants without direct access to the system need to enter data. Below, we show you exactly such an example of using configuration packages as templates.


Practical example: Export templates for article data

In the following example, we create an export template for article master data. The goal is to combine all relevant tables in a configuration package without exporting existing article data from a live database.

Step 1: Create a new configuration package

First, we open the Configuration Packages section in Business Central. There, we create a new package and give it a meaningful name. For example, we could call it "Article Export. " Clear naming makes reuse and maintenance easier later on.

Step 2: Add tables

In the next step, we add the tables that are relevant for the article master data exchange. In our example, these are:

  • Article (Table 27)
  • Warehouse booking group (Table 94)
  • Units (Table 204)

It is important that you consciously limit yourself to the tables that are actually needed and relevant. Each additional table increases the complexity of the package and can create unnecessary dependencies.

Step 3: Set filters – particularly important for templates

To ensure that no existing data records are exported when creating a template, filters must be set. To do this, each table within the configuration package is opened and specifically restricted, for example to certain article types or the status "not blocked."

Step 4: Exclude configured tables

In addition, you should set the "Exclude configured tables" field to Yes. This prevents unnecessary tables, such as system tables, from being included in the export template.


Using configuration packages with the example of customer addressee maintenance

To further illustrate how configuration packages work, the following example shows you how to maintain customer master data in Microsoft Dynamics 365 Business Central. Address and contact details such as street, postal code, city, or country/region codes are particularly prone to errors in day-to-day business. This applies both when creating new customers and when updating existing master data.
However, once the relevant tables and fields have been configured correctly, you can conveniently maintain this data via Excel – even by people without direct system access. Correct field and processing logic is crucial for a smooth import.

Step 1: Relevant fields in the customer card as a starting point

The starting point for every configuration package is the customer card in Business Central.
Here you will find all address and contact fields that are to be processed later via the configuration package: for example, street, postal code, city, country/region code, telephone number, or email address.
These fields form the technical basis for the subsequent package definition. It is advisable to check in advance exactly what information is actually required in order to keep the scope of the package targeted and clear.

Step 2: The package card as the foundation for structure and processing

The package card is the central control element of the configuration package. Here you specify which tables are processed, which options are active, and in which order the data is imported. Especially with more complex master data such as addresses, this configuration determines whether the import runs without errors or fails due to validation rules.

Step 3: Configure package fields – the core of data logic

In the field configuration, you define which fields of a table are exported and imported. In addition, validation rules, mandatory fields, and optional settings are taken into account here. Especially with address data, it is important to include only the fields that are actually needed and to configure them carefully. A clean field definition reduces sources of error and ensures traceable import results.

Step 4: Field order vs. processing order

One point that is often underestimated is the difference between field order and processing order.
The field order only determines the column arrangement in the Excel file. The processing order, on the other hand, controls the technical order in which Business Central checks and processes the fields during import.
A correct processing order is essential, especially for dependent fields such as country/region code, postal code, and city.

Step 5: Why the order of country/region code, postal code, and city is crucial

Address data is subject to relational checks in Business Central. The country/region code forms the basis for the postal code logic, and the postal code in turn is a prerequisite for the location. If this sequence is not followed, validation errors may occur during import, as Business Central attempts to access records that do not yet exist or have not been assigned.

Step 6: The crucial catch with "Create missing codes"

The "Create missing codes" option plays a central role in address data maintenance. As shown in the screenshot for step 4, you will find the corresponding button in the same overview where you specify the processing sequence. If this option is enabled, Business Central automatically creates missing postal code and city records if they do not already exist during import. This prevents import interruptions and ensures that the data can be transferred in its entirety. The automatically generated records can then be checked and, if necessary, supplemented or corrected.

Step 7: Exporting the data

For actual data maintenance, you can export the configured master data as an Excel file.
This file is ideal for collaborating with people who do not have direct access to Business Central, such as specialist departments or external parties.

Step 8: Import back to Business Central

After editing the Excel file, you can import the data back into the configuration package and process it from there. Thanks to the previously defined field and processing logic, the import is structured, traceable, and significantly reduces the risk of errors.

Best practices for using configuration packages

In practice, a few basic rules have proven useful, which we would like to share with you:
You should only use relevant tables and fields to keep the amount of data manageable. Use filters consistently to maintain control over the export. We also recommend that you check each export file before editing it and, above all, document configuration packages so that they remain comprehensible to other team members.

Did you know?

When importing data, missing codes for links can be created automatically. This is particularly helpful if you do not know which values will be supplied for a linked table, such as units.

This allows master data to be imported without disruptive error messages. The automatically created data records can then be checked and completed if necessary, for example using an additional configuration package.

Our conclusion


The key factors here are the correct processing sequence, clean field logic, and the deliberate activation of options such as "Create missing codes." Consistent use of configuration packages reduces sources of error, improves the quality of your data, and stabilizes your processes in the long term. Especially when it comes to address data, the correct order of country/region code, postal code, and city is a key success factor.

Another tip from us: Create precise internal work instructions for clean data maintenance. This will save you time and money in the future and make necessary, recurring tasks reproducible. You can also test your configuration packages in a sandbox first and document the validation rules.

Have you already optimized your export templates?

There are many other possible applications, such as transferring processed data, including associated master data, from a TEST system to a LIVE system, or quickly and sensibly reducing the fields to be exported across multiple configuration packages.


About the author

MARTIN BENZIN · Senior Functional Consultant

Space for your comments

Scroll up

Discover more from PROTAKT Projekte und Business Software AG

Subscribe now to continue reading and access the entire archive.

Read more