What a Dynamics 365 F&O database refresh does not copy, and what breaks after it

A database refresh is the most common thing an F&O environment owner does and the one with the longest list of side effects. Microsoft's page on it (ms.date 3 April 2026, updated 1 September 2026) is accurate and complete. It is also organised as prose, so the people who get burned are the ones who read it once, months ago. This article turns it into the checklist, and adds the one thing Microsoft does not say: what the list means if an AI agent runs in that sandbox.

For the person who runs the monthly refresh and takes the calls afterwards. 6 minute read.

What a refresh is, in Microsoft's words

"Use Microsoft Dynamics Lifecycle Services to refresh the database in a sandbox user acceptance testing (UAT) environment." The path is the target sandbox's Environment Details page, Maintain, Move database. The operation copies the application and Financial Reporting databases from production into the sandbox and "deletes the original target database."

Two rules sit next to the steps. "Schedule the refresh database operation during off-peak hours and limit the operation to one refresh at a time," because the copy reads production while production is working. And: "Copying production data to your sandbox environment for the purpose of production reporting isn't supported." A refreshed sandbox is a test environment, not a reporting replica.

The checklist: what the refreshed sandbox will not have

Every item below is from the refresh page's own list, grouped by who has to fix it.

Access

• "All users except the admin are set to Disabled status." Re-enable the testers, and only the testers.
• "All users have their partition value reset to the 'initial' partition record ID."
• The admin account is reset to the value in web.config, which is the Lifecycle Services administrator.

Scheduling

• "All batch jobs are set to Withhold status." Release the ones the test needs; leave the ones that would email customers or post to external systems.

Secrets

• "All Microsoft-encrypted fields are cleared, because they can't be decrypted on a different database server." The example on the page is the SMTP password in SysEmailParameters. Every stored credential follows the same rule.

Integration

• "Service endpoints for business events and data events are removed."
• Dual-write must be re-linked through "Enable Power Platform Integration."
• "The Admin user must make required configuration changes, such as reconnecting integration endpoints to specific services or URLs."

Files

• "No file stored in Azure blob storage is copied... This restriction includes document attachments and custom Microsoft Office templates."

Scrubbed on purpose

• Email addresses in LogisticsElectronicAddress, and the SMTP relay in SysEmailParameters, so a test cannot reach a real customer.
• Print management settings.
• Environment-specific records in SysServerConfig, SysServerSessions, SysCorpNetPrinters, SysClientSessions, BatchServerConfig and BatchServerGroup.
• Dimension log and cache tables; maintenance mode is disabled; change tracking is disabled.

The conditions that refuse a refresh

• Platform update 20 or earlier: refused.
• Financial Reporting in the target must be at or above the source version.
• "You can't refresh an environment from one tenant to another."
• The refresh "affects only the application and Financial Reporting databases." Anything else attached to the environment is untouched.

What breaks the next morning, in order of how often we see it

1. An integration that silently stopped. The endpoint was removed and the credential was cleared. Nothing errors until the first message is due.
2. A batch job that someone released in bulk, including the one that emails statements. The scrub of email addresses is what saves you, which is why you should never "fix" the scrub.
3. A test that fails on a missing attachment. The record is there, the file is not, because blob storage is never copied.
4. A user who can log in to production but not to the sandbox, because the refresh disabled them and the re-enable list was built from memory.

If an agent runs in this sandbox

An AI agent that reads F&O does so as a user, under a security role, usually through a registered application and often through a business event or data event endpoint. Read the checklist again with that in mind: after a refresh its user is disabled, its endpoint is removed and any stored secret is empty. That is the correct outcome, and it means the agent's sandbox setup is a repeatable script, not a one-time configuration. In our own builds, re-registering the agent's access after a refresh is a step in the runbook, not an incident. If your partner or vendor has not written that step down, ask for it before the next refresh.

Is the refresh moving to the Power Platform admin center?

The refresh page itself does not mention the admin center. The unified admin experience overview (ms.date 10 September 2026) maps the Lifecycle Services "Database refresh" to the admin center's "Copy", with one difference worth knowing: in Lifecycle Services the operation "only copy data," while in Power Platform "code is always copied with data." For an environment migrated to the admin center under the September 2026 preview, the refresh you know becomes a copy that also carries code. Plan the test cycle around that before migrating a sandbox.

What to do this week

1. Turn the list above into a refresh runbook with an owner per line: who re-enables users, who releases which batch jobs, who re-links dual-write, who re-registers each integration and each agent.
2. Record the refresh date on the sandbox. It resets the sandbox's seven-day backup window.
3. Stop recurring data management jobs before the refresh and schedule it off-peak, one at a time.
4. If a sandbox is about to be migrated to the admin center, run one refresh afterwards as a test, because copy-with-code is a different operation.

Sources

• Microsoft Learn, "Database refresh", ms.date 2026-04-03, updated 2026-09-01: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/database-refresh
• Microsoft Learn, "Unified admin experience for finance and operations apps", ms.date 2026-09-10: https://learn.microsoft.com/en-us/power-platform/admin/unified-experience/finance-operations-apps-overview
• Microsoft Learn, "Migrate finance and operations environments from Lifecycle Services to Power Platform admin center (preview)", ms.date 2026-09-22: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/lifecycle-services/migrate-lifecycle-services-environments-power-platform-admin-center
• Microsoft Learn, "Database movement operations home page", ms.date 2026-04-03, updated 2026-09-01: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/dbmovement-operations

All read 22 October 2026.