Environments in Business Central

Environments in Business Central

The ERP Manager guide is written by Abakion. Read it here and download it as PDF free of charge.

As an ERP manager you need to know the Business Central admin center and understand the structure of tenant, environments, and companies. You also need to know when you need additional production environments and how to manage your sandboxes.

How to access the admin center

You access the admin center through your Dynamics 365 account. You can also go directly there from Business Central by clicking the gear icon in the upper right corner and selecting “Admin Center”. This requires you to have the right administrator permissions.

If you don’t have access to the admin center, you should demand it internally. Without access you can’t create sandboxes yourself, update apps, or look across environments, and that slows you down in your work as ERP manager. It is hard to take responsibility for a solution you don’t have access to administer.

What you can do in the admin center

In the admin center you can:

• manage your environments, both the production environment in operation and the sandboxes
• manage which apps are installed on each environment
• see whether updates have been released for the apps you use
• schedule timing for upcoming updates from Microsoft

The three levels: tenant, environment, and company

Business Central is structured in three levels:

A user with a license on your tenant can by default work across all environments in the tenant, but you can restrict access through permissions inside the individual environments.

Any apps you install apply to the entire environment and are shared across the companies in the environment.

How many environments you get by default

By default you get the following with your subscription:

• 1 production environment
• 3 sandbox environments

If you need additional production environments, for example because you operate in several countries, you can purchase them through your partner. Each additional production environment gives you three additional sandboxes and additional database capacity.

Environments across countries: one localization per environment

If your company has activities in several countries, you must decide how to organize your environments. It is a decision that has major implications for everyday work.

Each environment in Business Central is bound to one localization: one country’s legislation, VAT rules, bank formats, and reporting requirements. A given country’s localization is set up according to that country’s accounting legislation and differs on critical points from other countries’ localizations. The choice of localization is made when the environment is created and cannot be changed afterward.

Why multiple countries in the same environment cause problems

Some companies have multiple countries’ companies together in one environment. This creates problems when your environment is set up with one country’s localization and you have a company from another country in the same environment. The second country’s company then follows the first country’s rules on the points where localization governs. That doesn’t work in practice.

But there are many differences between countries, for example payment formats: different countries use different national payment schemes such as country-specific giro systems, direct debit schemes, or checks.

Compliance requirements tighten the demands further

Compliance requirements are getting stricter. Many countries have introduced requirements for digital receipts, and there are also growing demands for SAF-T reporting. One country’s Business Central cannot meet the requirements that another country’s version is built for. Each country’s company must sit in an environment with the right localization.

Best practice: one production environment per localization

A company in one country with a subsidiary in another country should create two production environments: one with the first localization for the local business units, and one with the other localization for the subsidiary. The users are defined in the same tenant and can work in both environments. This is the setup that makes sense for most international companies.

Sandboxes: development and testing

You should have a sandbox environment where you can test apps and try out new ideas and possibilities. If you have new functionality developed for Business Central, you also need a dedicated development environment.

There is no environment type called “development environment” in Business Central. There are production environments and sandboxes. You can dedicate one of your three sandboxes to serve as a development environment.

Never test directly in the production environment

As ERP manager you must prevent anyone from:

• testing directly in the production environment
• installing an app in the production environment without prior testing
• enabling new features in Feature Management without testing
• otherwise putting something into operation without testing it in a sandbox

Why a bug in production grows explosively

If you put code into production and find a bug, it is far more involved to fix than finding the bug in a development environment. You not only have to fix the code. You also have to correct or reverse all the transactions and data that have been generated incorrectly while the bug has been in operation. The system keeps generating incorrect data until you fix the bug, so you are under time pressure to stop the damage. The cleanup work can grow explosively relative to how small the original bug was.

Testing is also an opportunity to learn

Testing isn’t only about catching bugs. It often happens that you learn something along the way. Your ERP partner has developed exactly what you asked for, and it works flawlessly, but when you try it out you find that you forgot something, or that it could work more cleverly in another way.

The devil is often in the detail of special exceptions to processes, and even experienced users and consultants cannot think through all potential scenarios in advance. In a sandbox it is no problem to learn something new. In the production environment it leads to cleanup that could have been avoided.

How to create the right sandbox

Create a copy of your production environment as a sandbox and test the new functionality there. That gives you a test environment that is a true copy of your operations, and that gives the best test. Remember to delete old sandbox environments from previous testing. You can delete them yourself in the admin center or ask your partner to do it.

Naming policy for sandboxes

When you create a new sandbox, give it a name that tells who created it and when, for example with initials and date. Then you know afterward who you need to ask whether the sandbox is still in use or whether it can be deleted.

Internal sandbox policy

You should have an internal policy for sandboxes. You need answers to:

• how many sandboxes you keep running
• who may create sandboxes
• who decides when they are deleted

Some companies have a fixed development sandbox with apps and configurations enabled, a generic test sandbox for broader testing, and a free sandbox for quick copies of the production environment when a specific process needs to be tested. Other companies do no development and rarely need more than one sandbox at a time. Find the model that fits your everyday work.

What happens in a sandbox: processes that are stopped

When you create a sandbox as a copy of the production environment, a number of processes are automatically stopped to avoid unintended actions toward customers and external systems:

This means you can post an invoice without a job queue sending an email with the invoice to your customer. You can enter test data without integrations synchronizing it to other systems.

Also test your own apps and PTEs

If you have had your own functionality developed or have installed apps, you must as ERP manager ensure that they also behave correctly in a sandbox, so that they don’t send or synchronize anything you don’t want.