NewsCompanial, Ciellos and Simplanova go further as one.Companial, Ciellos and Simplanova go further as one.Take a look

Blog |

Business Central

Mastering Business Central: Navigating Tenants, Environments, Companies, Countries, and Licenses with Ease

Monday, October 7, 2024
Reading time: 14 minutes

As a Microsoft Dynamics Partner, managing customers with multiple companies across different countries, each with its own Microsoft 365 infrastructure, can be daunting. Adding to the complexity, you’re tasked with deploying Business Central into environments that may not be fully optimized for it. Whether your customers are consolidating Business Central instances or expanding by acquiring companies with existing Business Central deployments, you need to know how to make it all work seamlessly.

In this blog, we’ll dive into the key challenges you’re likely to face and explore how to piece the puzzle together—from managing multiple tenants and environments to configuring licenses and ensuring cross-company collaboration. These fundamentals can save you headaches down the line. Today, we’ll cover the essential knowledge to help you navigate this landscape with confidence, as I often find that many of the questions, I get asked daily by partners come back to understanding these basics.

Overview

Figure 1: How a Tenant, Environment and Company relate to one another in Business Central

The first thing we must understand is the Tenant, Environment, and Company – what they are, what their roles are, and how they relate to one another. The diagram above shows a good example of how they fit together, but the devil is in the details. Let’s look at each one individually.

Tenant

Let’s start with the Tenant. In Microsoft 365, a Tenant is a dedicated, cloud-based instance assigned to an organization, used to manage its services, users, and subscriptions. It contains resources like Microsoft 365 apps, users, groups, and security settings. That’s a mouthful, but let’s break that down. Essentially, every organization owns a Tenant. I say “organization” and not “company” because some organizations own multiple companies, and they will generally not have a Tenant per company—only per organization. (More details on this in the Company section later on).

This Tenant will typically contain services, apps, and subscriptions. For instance, they may have a subscription to Office 365 (now called Microsoft 365, of course), which gives them access to Outlook and Exchange for email, along with Excel, PowerPoint, and other tools. They may have other subscriptions too, including Business Central, Customer Engagement, or Power Platform. The important thing to note is that licenses are purchased at the Tenant level and belong to the Tenant.

Microsoft Entra (this feature was formerly known as Azure Active Directory) provides identity and access management for the Tenant, controlling who has access to what resources. Think of Entra as a database containing usernames and passwords. Of course, it’s more complex than that, but this is also where you assign the licenses you’ve purchased to your users.

Image 2: Microsoft Entra in a Tenant

A key part of the Tenant is the Tenant ID, a unique identifier known as a GUID (Globally Unique Identifier), which looks like a long string of letters and numbers (e.g., 695ba6c0-cbe1-574d-v01b-16321c192c45). This is how the Tenant is identified in Microsoft’s infrastructure, ensuring no two Tenants have the same GUID.

Now, I know this is super basic, but bear with me—we’re building the foundation here.

Every user you create in the Tenant has a format like their email address: user@mycompanydomain.com. This associates the company domain with your Tenant. Sometimes you may have more than one domain associated, such as maincompany.com and subsidiary.com, or mycompany.com and mycompany.co.uk. A user can have multiple email addresses tied to different domains but only require one license—if they belong to the same Tenant. Here’s how that works:

Figure 3: One user with multiple domains associated.
Sometimes an organization will have multiple Tenants for different companies. As seen below, sometimes each company in a group, or global offices of the same company, will have its own Tenant.
Figure 4: Two different Tenants each with their own domain.

Don’t get confused – you could have one Tenant with two domains, where user1 is user1@mycompanydomain.com and user2 is user2@mycompanydomain.co.uk. Or, you could have two separate Tenants, each with its own domain.

Let’s now talk about licensing in these two scenarios. If I have one Tenant and two users, I will need two licenses—one for each user, both with access to everything. However, if I had two Tenants (user1 in Tenant1 and user2 in Tenant2), then each user would only have access to their Tenant’s resources. If user1 needs access to Tenant2’s resources, I would need to purchase an additional license for user1. This is when things may get a bit costly. However, it’s more nuanced depending on what user1 needs access to, as Microsoft 365 does allow certain resources to be shared across Tenants without additional licenses. But that’s a topic for another blog.

Environments

Congratulations on making it this far! Now let’s talk about Environments. Within a Tenant, an Environment is a space where specific resources, apps, or services are isolated and configured for different purposes, like development, testing, or production. While commonly used in Dynamics 365 for Business Central or Power Platform apps, Environments are also used in other Azure resources to organize and control services like databases or virtual machines.

In Business Central, there are two basic types of Environments: Production and Sandbox. Production environments are for live, operational use, while Sandbox environments can be used for development, testing, or training (more on this later). Production environments have higher performance and are backed up regularly, as they contain critical data.

You can’t purchase a Sandbox environment on its own—it’s packaged with Production environments. For every Production environment you purchase, you receive three Sandbox environments. Unfortunately, Sandbox environments cannot be bought separately.

When you create an Environment, you must associate it with a country. Only countries where Business Central is available can be selected. Choosing the correct country ensures that the version of Business Central deployed complies with local legislation, tax regulations, and accounting standards specific to that region.

Additionally, the selected country determines the Azure datacenter where the Environment will be hosted. For instance, the only datacenter in Africa is in South Africa, so environments for Namibia, Botswana, or Zimbabwe will be hosted in South Africa. If you’re operating in the US, for example, and select the US as the country for your Environment, it will be hosted in a US datacenter, ensuring minimal latency for users in that region.

I often find that many misunderstand this point, thinking that data for all countries in a multi-national deployment is hosted in one datacenter. In reality, each country has its own production Environment in its closest datacenter.

Company

Now we get to the Company level in the Business Central architecture. Essentially, you create a Company for every legal entity or juristic person you need. Some businesses create multiple companies for various reasons, such as a holding company with subsidiaries, or splitting the ownership of assets.

In Business Central, you can have multiple companies in one Environment, but there is a limit of 300 companies per environment. If you exceed this, you can purchase another Production environment. (This limit is only from 2023 Release Wave 1 or v22, before that there was no limit imposed)

One important question I often get is about intercompany operations, like consolidations and intercompany transactions, across Tenants and Environments. Thankfully, Business Central supports intercompany transactions even across different Tenants and Environments.

Another important point to clarify is about the eligibility of companies that can be hosted on the same Tenant. According to the Microsoft Customer Agreement, that governs Business Central Online, affiliates of the Customer are allowed to use the Tenant. The agreement defines “affiliates” as legal entities under common control, meaning ownership of at least 50% voting securities.

This means that only companies you control or own at least 50% of can share a Tenant for Business Central. This has been true for on-premises licenses and continues in the cloud. Read more about this in your own agreement, but as example here is a link to the US Customer Agreement.

Master Data Management

In Business Central, there is a feature called Master Data Management, which helps synchronize master data, such as Customers, Vendors, and G/L Accounts, across companies. You can select specific tables and fields to keep synchronized. However, this feature is currently limited to companies within the same environment. This was true at time of writing this article, but may change, so it’s important to stay updated by checking the feature documentation here.

This is something that Microsoft was planning to add to Business Central, but the Idea has not been implemented yet, you can vote for the idea on aka.ms/BCIdeas, here is a link to the suggestion.

Tenant or Environment Licensing

A common question is whether Business Central licensing applies to a Tenant or an Environment. When a user license is purchased, it is assigned at the Tenant level through Microsoft Entra. Once a user holds a Business Central license, they are licensed to access any environment and any company within that tenant. Of course, you can restrict access through user permissions, as not every user should have access to every company. However, the license itself allows them to access all companies, should permissions allow it.

Permissions are assigned firstly to the Environment with Security Groups, and then with Security Groups and Permission Sets per Company, but that is a topic for another BLOG. All this reminds me about Essential and Premium licenses, let’s look at those.

Essential and Premium Licenses

When discussing Business Central, it’s essential to understand the differences between the Essential and Premium versions. The Essential version includes most of Business Central’s functionality, excluding Service Management and Manufacturing, which are only available in the Premium version. Companies must choose either the Essential or Premium version, as all users in the company need to be licensed accordingly. Essential licenses are more affordable than Premium licenses.

If a company has five entities, and only one requires manufacturing, only the users working in that company need Premium licenses. The other four companies can use Essential licenses, but it’s important to note that you cannot mix Essential and Premium versions in the same environment. All companies within an environment must use either the Essential or Premium version. While Premium users can access Essential environments, users with Essential licenses cannot access Premium environments.

The solution is to have two environments: one for Premium and another for Essential. The company that requires manufacturing would be added to the Premium environment, while the other four would remain in the Essential environment. Users who need access to both environments require Premium licenses, while those working exclusively in the Essential environment only need Essential licenses.

Sandbox Usage and Management

You only get 3 Sandbox Environments on most deployments of Business Central, and yet you need to use these environments for various reasons. Development, User Acceptance Testing, Training, previewing new features, testing of developments against new features. Various questions are very often asked by partners about how they are supposed to manage these environments. Let’s quickly talk about this.

Firstly, it’s a playground where you can test, you cannot export data with the database export feature. This you can only do with Production environments. If you need data out of a Sandbox environment, you’re going to have to rely on the RapidStart or Export to Excel features.

The 3 Sandboxes that you get with the Production environment are the customer Sandboxes, leave these Sandboxes for the use of the Customer. As a partner, you also get access to one Partner Sandbox, read this nice BLOG by Stefano Demiliani here or read about it on the official Microsoft Documentation here that covers everything about environments.

Please read the Microsoft Documentation for further information on Sandbox environments.

Every employee in the partner organization also has access to 1 CDX trial environment of Business Central where they will also get access to 1 Production and 3 Sandbox Environments. Read more about that here or go to aka.ms/cdx

Tenant Size Limits

I need to mention that there is a limit on the size per Tenant in Business Central Cloud. When purchasing your first Essential or Premium user, you are assigned a basic allocation of 80GB to your Tenant, this limitation is applicable to the sum of the Environments.

You are then allocated 1GB extra storage for every Device User, 2GB extra for every Essential user, and 3GB extra for every Premium user, and 4GB for every extra Production environment you have purchased.

You can then optionally purchase extra space if the allocated size is not enough, but read more about this here.

Further Reading

Partners also get access to their customers’ Business Central Environments, they can do so to support the customer, and assist with support, upgrades, developments, testing and whatever else the customer requires assistance with. Read more about Delegated Admin access here.

Data residency is something that must be considered when deploying Environments in Business Central, in some countries data is not allowed to be stored outside of the borders of the country. This topic goes beyond Business Central however, read more about this in general here.

If different partners across the globe are responsible for different Environments in Business Central, you can restrict access to Environments with security features. Read all about that in this article.

Conclusion

As you can see, there are many factors to consider when designing a Business Central deployment for a multi-company, multi-national, or a combination of both. Adding a mix of Essential and Premium licenses into the equation requires careful planning to ensure an efficient and compliant setup for cloud deployment.

Apologies for the length of this BLOG, it is a lot longer than I had planned, but I hope that you have found value in the topics discussed. Please stay up to date with licensing and deployment changes by regularly attending webinars on the topic and looking out for updates from me.

I will be hosting a training webinar on this topic hosted by Directions for Partners on the 27th of October, talking about everything covered here and more. As soon as a link is available to this webinar, I will update this BLOG, so if you don’t see a link here, please check back soon, or have a look on the Directions page for upcoming webinars.

While there are always more details to explore, I realize this is already a lot to take in, so I’ll pause here for now. 

Berny Düring
Latest posts by Berny Düring (see all)

More about Business Central