What happens, behind the scene when an environment is copied, how do we prevent rogue code execution in the copy? In this video, I show how you should prepare your code for environment copying. Check it out:
In this video, Erik explains an important but often overlooked responsibility for Business Central developers: cleaning up custom app configurations when environments are copied. While Microsoft handles cleanup of base application settings automatically, your extensions need to handle their own cleanup using dedicated events.
The Problem: Environment Copies and Unintended Side Effects
In Business Central cloud, system administrators have the ability to copy an environment — typically copying production to a sandbox. This poses an interesting challenge because a production environment often has:
- Job queues that send out invoices
- Connections to external web services that pull in data
- Automated processes running on schedules
If these all started running in a freshly copied sandbox, you’d have a disaster on your hands — the sandbox could pull transactions before production does, trigger duplicate operations against external services, or generally create a huge mess. As Erik puts it: “by just copying a sandbox you have basically destroyed lots of things and all the users hate you.”
What Microsoft Already Handles
Fortunately, Microsoft has thought about this. When you copy an environment, the platform automatically performs several cleanup actions:
- Tasks in the job queue are stopped
- Base application integration settings are cleared (such as CRM integration)
- Features enabled in the original environment are turned off in the copy
- Outbound HTTP calls from extensions are blocked by default and must be re-approved
- Various setups are set to disabled — document exchange, currency exchange rate services, and more
This is great, and it prevents a lot of headaches. But there’s one critical gap: what about all the stuff in your extensions, customizations, and apps?
Your apps are not on Microsoft’s cleanup list. Your customizations are clearly not on this list. So how do you handle it?
The Solution: Environment Cleanup Events
Business Central provides a dedicated codeunit called Environment Cleanup that publishes events specifically for this purpose. There are two key events you can subscribe to:
OnClearDatabaseConfig
This event fires for settings that are stored at the database level (not company-specific). Use this when your extension stores global configuration that should be disabled or cleared in a copied environment.
codeunit 50100 "My Environment Cleanup"
{
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Environment Cleanup", 'OnClearDatabaseConfig', '', true, true)]
local procedure OnClearDatabaseConfig(SourceEnvironmentType: Option Production,Sandbox; DestinationEnvironmentType: Option Production,Sandbox)
begin
if DestinationEnvironmentType = DestinationEnvironmentType::Sandbox then begin
// Disable database-level settings here
// For example: clear isolated storage secrets,
// disable global integration switches, etc.
end;
end;
}
OnClearCompanyConfig
This event fires once per company and is for settings stored at the company level. The parameters include the company name, so you can target your cleanup to company-specific setup tables.
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Environment Cleanup", 'OnClearCompanyConfig', '', true, true)]
local procedure OnClearCompanyConfig(CompanyName: Text; SourceEnvironmentType: Option Production,Sandbox; DestinationEnvironmentType: Option Production,Sandbox)
begin
if DestinationEnvironmentType = DestinationEnvironmentType::Sandbox then begin
// Disable company-level settings here
// For example: disable active/inactive switches in setup tables,
// clear credentials, disable scheduled integrations, etc.
end;
end;
What Should You Clean Up?
The specifics depend on what your extension does, but here are common examples:
- Credentials and secrets stored in isolated storage — you likely don’t want production secrets carried over to a sandbox
- Active/disabled switches in your setup tables — if you have an “Enabled” toggle for an integration, set it to disabled
- External service endpoints — sandbox should not point at production APIs
- Scheduled or automated processes specific to your app
Erik specifically mentions the SharePoint connector as an example where credentials stored in isolated storage should be cleared during environment copy. (For more on isolated storage, Erik recommends his video on “The Secret Keeper” codeunit.)
Why This Matters: User Expectations
Customers have learned that when they copy an environment, job queues stop and base integrations get disabled — because that’s what Microsoft does automatically. They now expect your extensions to behave the same way. If your app continues firing off requests to external services or processing data in a copied sandbox, that’s a serious problem and a poor user experience.
As Erik notes, more and more customers are regularly refreshing their sandbox environments from production. It’s become a routine operation, and your apps need to handle it gracefully.
Conclusion
Subscribing to the OnClearDatabaseConfig and OnClearCompanyConfig events in the Environment Cleanup codeunit is a simple but powerful way to be a responsible app developer. It’s one of those things that isn’t written on the package, but it’s a really good idea. Two simple event subscribers can save your customers from a world of pain — and make you a good friend to everyone who copies environments.
