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.
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.
In terms of licensing, you're likely operating with three different object ranges. All tenants can freely use objects in the following ranges:
50,000-99,999
1,000,000-60,000,000
70,000,000-74,999,999
The following sections explain the intention of each individual range.
Range: 50,000-99,999
This range is for each tenant/customer customization. A partner can develop an extension that is tailored to the individual tenant to fit their needs. The partner who develops this extension will do so by using a sandbox tenant or by obtaining a Docker image of the current Business Central release that matches the version of the tenant. After the development is complete, the extension can be deployed to the individual tenant.
Range: 1,000,000-60,000,000
This range is the Registered Solution Program (RSP), which is reserved for developing partners that have an ISV solution. The partner can choose to use this range for developing extensions that can be used in Microsoft Dynamics NAV on-premises or in Dynamics 365 Business Central in the cloud. When used in Dynamics 365 Business Central, these extensions usually can be obtained as apps from AppSource.
Range: 70,000,000-74,999,999
Partners can obtain ranges for extension development that run in Business Central. These ranges are only available for extension development and are also obtained as apps from AppSource.
For additional information about Microsoft AppSource, view the Ready To Go Program.
Prefix and suffix
Along with the requirement that each object should have its unique number, each object should also have a unique name. Two tables should not have the same name. Business Central allows you to install multiple extensions, and some of these extensions can come from AppSource. AppSource is a central marketplace where you can purchase extra and new functionality for Business Central.
The probability is great that you might install extensions that have the same name for a table. To solve that issue, you as a developer should use prefixing or suffixing.
A prefix or suffix in Business Central is a tag of at least three
characters. Each object that you create should start or end with this
tag. If a conflict arises, the one who registered the tag always wins.
To register your own tag (for example, for your company), you must send an
email to d365val@microsoft.com to reserve your prefix and/or suffix.
For every object (pages, tables, codeunits, and so on), specify the tag at the top object level.
Apps in AppSource are required to register and use a prefix or a suffix. Only in vary rare cases will apps run into naming conflicts.
Per-tenant extensions are not 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.
General rules
The prefix/suffix must be at least 3 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 pages/tables/codeunits, you must set the prefix/suffix at the top object level.
For pages/tables 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 level.
Use the AppSourceCop tool to find all missing prefixes and/or suffixes. The Rules section explains the different checks that the analyzer will do. For prefix/suffix detection, refer to the Configuration section. It explains how to set your prefix in the AppSourceCop.json file.