Discover the logical database and its objects
Dynamics 365 Business Central is built, like many other cloud applications, on top of a database. This database doesn't only contain the data (like customers, vendors, products, and so on.); it also contains every object that is used in the application. When you request customer data, this data is displayed as a page on the screen with a certain structure.
Business Central's database also stores the structure of this page, which allows developers to add and modify existing objects and deploy new solutions quickly. You do not need to build a new version of the product when you want to change the position of certain input fields on the screen.
Every solution is built on one or more objects. You'll need tables to store your data, pages to present your data, the ability to allow user interaction, reports to present, and the capability of printing data in specific layouts.
With codeunits, you can group functions to be reused in different places. You can use the Query object to query the database, and when you need importing or exporting capabilities in your solution, you'll use the XMLPort object.
The commonly used object types include:
Table - Describes how data is stored and how it's retrieved.
Page - Enables users to view, add, modify, or delete records in a table.
Report - Print, process, or preview the data.
Codeunit - Container of programming code. Codeunits are called from other objects to complete a specific task.
Query - A relational data model for direct and efficient querying of the underlying database.
XMLPort - Imports or exports data in XML or text format.
Business Central has many built-in functionality objects. You can't change the source code of the objects, but you can modify the behavior by extending the built-in objects.
Two other object types that you can use are:
Table Extension - Extends the functionality of existing tables.
Page Extension - Extends the functionality of existing pages.
Report Extension - Extends the functionality of existing reports.
Logical database
In the Business Central database, you can set up different companies. The data of a company is stored as records in different tables, and each record is built out of multiple fields.
Companies are the largest logical structure in a database and data is, and should be, mostly company-specific. While data is mostly company-specific, objects aren't. As a developer, you'll create and change/extend objects. The objects will then be applicable to all companies within the same database.
Manage objects
Before you start making new objects for your customized solutions, be aware of object numbering conventions. Each object in your Business Central solution is identified by a unique number. Numbering conventions help you organize version management, localization, and customization, and help you ensure successful upgrades.
The object numbers from 0 to 49,999 are objects that are used by Microsoft and they're used in the worldwide versions. The number range from 100,000 to 999,999 contains the localized objects. These objects are typically designed for different countries and regions of the world. These area-specific objects are also created by Microsoft.
When you develop an app for Business Central online, you must request an object range in terms of licensing. Development for Business Central is done using Visual Studio Code with the AL Language extension for Microsoft Dynamics 365 Business Central.
There are currently two available ranges that you can request. Both have some characteristics to keep in mind:
RSP Object Range (ID range 1,000,000-69,999,999) - This object range is tied to the RSP Program. You need to log on to view this information using a work or school account. We currently advise new publishers not to request an RSP object range.
App Object Range (ID range 70,000,000-74,999,999) - This object range was originally designed just for apps in the Microsoft commercial marketplace to be used in Business Central online. We currently advise new publishers to request an app object range.
Currently, you can implement apps developed in both the RSP range and the app object range in Business Central online and on-premises, as well as partner-hosted.
For more information, see Requesting an object range.
The following sections describe the different object ranges that you can find in the base application and extensions.
0-49,999
This range is assigned to Business Central base app functionality and mustn't be used in extensions or customizations.
50,000-99,999
This range is for customizations, and for test purposes. For Business Central online, a partner can develop an extension tailored to the individual tenant to fit the needs. The partner develops the extension either by using a sandbox tenant or by obtaining a Docker image. Once the development is done, the extension can be deployed to the individual tenant.
Also, you can use this range as part of training and/or similar endeavors, such as if you're using a sandbox tenant or a build of Business Central on Docker.
100,000-999,999
The objects in this range are designed when the Microsoft team localizes Business Central for a specific country or region. These objects can't be used by partners.
1,000,000-69,999,999
This object range is intended for the Registered Solution Program (RSP). The partner can choose to use this range for developing extensions that can be used in Business Central online or on-premises. When used in Business Central online, these extensions are obtained as apps from Appsource.
70,000,000-74,999,999
Partners can obtain IDs in this range for extensions for Business Central online. These extensions are obtained as apps from Appsource also. For more information, see Get Started with Building Apps.
See licensing guides to download the Business Central licensing guide.
Prefix and suffix
In your extension, the name of each new application object (table, page, codeunit), must contain a prefix or suffix. This rule applies to all objects. You can use the Caption values for what you decide to display to the user. When you modify a core Dynamics 365 object using a table extension or a page extension, the prefix/suffix must be defined at the control/field/action/group level.
Benefits
The use of a prefix/suffix reduces name collisions with objects defined in other extensions. Environments that have extensions with name collisions can experience issues when deploying new extensions, when upgrading the environment, or when creating a sandbox as a copy of the current environment (for production environments).
General rules
Here are some general rules to follow:
The prefix/suffix must be at least three characters
The object/field name must start or end with the prefix/suffix
If a conflict arises, the one who registered the prefix/suffix always wins
For your own objects, you must set the prefix/suffix at the top object level
For pages/tables/enums/reports/permissionsets in the base application or other apps that you extend, you must set the prefix/suffix at the top object level and also at the control/field/action/procedure/values/dataitem/column level
Use the AppSourceCop tool to find all missing prefixes and/or suffixes. Configuration options for this tool along with a rules section can be found at AppSourceCop Analyzer Rules. The Rules section explains the different checks that the analyzer does. For prefix/suffix detection, refer to the Configuration section. It explains how to set your prefix/suffix in the AppSourceCop.json file.
Prefix and Suffix requirements for extensions
There are some requirements for AppSource and tenant extensions.
For AppSource extensions
The use of a prefix/suffix for object names is required for AppSource submissions as part of the Technical validation checklist.
In order to meet the requirements for the AppSource technical validation, you must have a three letter prefix/suffix registered for your extension publisher, and you must use it in your extension.
If you don't have any prefix/suffix(s) registered yet, contact Microsoft at
d365val@microsoft.com and provide the following information to reserve the
prefix/suffix of your choosing.
Your MPN ID
The publisher name that you use in your extensions (in the app.json file)
You must provide at least five prefix/suffix suggestions. Each must be exactly three characters.
Prefix/Suffix(s) aren't case-sensitive, which means that for example "ABC", "abc", and "AbC" are treated as the same. Providing both "ABC" and "abc" counts as only one of your suggestions.
Note, that you aren't required to change any already registered prefix/suffix(s); you can continue using these. The guidelines only apply to new registrations.
For per-tenant extensions
Per-tenant extensions aren't required to use a prefix or suffix, but we strongly recommend that you do so. You can use pte as prefix or suffix to avoid conflicts with AppSource apps or base objects.
If your per-tenant extension causes a conflict with a new object in the base application or an updated AppSource app, then the per-tenant extension is required to make the change.
For more information about using prefixes or suffixes, see Benefits and guidelines for using a prefix or suffix.