A Sandbox refresh replaces the tenant, it doesn't merge into it

A Sandbox tenant exists as a copy of your Production tenant: same data, same configuration, on its own separate instance you can safely break. A refresh doesn't patch that copy or apply the differences since last time. Workday takes a fresh copy of Production, both its data and its configuration, and replaces the Sandbox tenant's contents with it. Whatever the Sandbox looked like the moment before the refresh is gone; whatever Production looked like at that moment is what the Sandbox becomes.

That distinction matters for planning. A change you made directly in Production before the refresh window survives, because it's now part of the copy Workday takes. A change you made only in the Sandbox, and never migrated up to Production, does not survive, because it was never part of the source the refresh copies from.

The refresh schedule, and how it differs by tenant

Workday refreshes the Sandbox tenant on a weekly basis, as a copy of Production, so it stays in line with the current deployment. The Sandbox Preview tenant is also a copy of Production, with functionality from an upcoming feature release layered in, and Workday refreshes it twice a year rather than weekly. An Implementation tenant is a direct replica of Production too, but Workday refreshes it on demand instead of on a fixed schedule, which is why teams use Implementation tenants for work that needs to survive longer than a week. 

Sandbox           weekly, copy of Production
Sandbox Preview   twice a year, copy of Production plus the next feature release
Implementation    on demand, direct replica of Production

If you're mid-way through a multi-day build and can't risk losing it to this week's refresh, an Implementation tenant is the documented way to buy time; Workday describes it as allowing testing outside the Sandbox tenant's standard weekly refresh window.

What actually gets wiped: anything that exists only in the Sandbox

Workday draws a line between metadata, the parts of Workday you can't change, and tenanted data, the configuration and records that make an instance yours. A refresh only touches tenanted data, but that's most of what you spend your time building: business process definitions, calculated fields, custom reports, security policies, condition rules, Workday accounts, and the values entered into any of them.

None of that survives a refresh unless it also exists in Production. A calculated field you built and tested only in the Sandbox, a security group you were still iterating on, a condition rule you hadn't migrated yet, an Integration System User whose Sandbox password you changed for a test, a web service configuration you pointed somewhere different for a trial run: all of it reverts to whatever Production has, because the whole tenant becomes Production's copy again. If Production doesn't have the object at all, the Sandbox won't either after the refresh.

Notification and messaging settings copy over too, and need resetting

Because a refresh copies Production's configuration wholesale, it also copies settings you specifically set differently in the Sandbox to keep it quiet. Workday's own setup guidance for SMS and WhatsApp messaging tells you to delete the copied Production SMS configuration that displays in a non-Production tenant after a tenant refresh, and to test SMS notifications in a non-Production tenant using a redirect restriction, so a test run doesn't reach a real candidate's phone.

The Edit Tenant Setup - Notifications task controls the same kind of thing for email: you can disable all email, mobile push, and SMS notifications for a given tenant. Treat any restriction you rely on to keep test notifications out of real inboxes as something to re-check after every refresh, not something you set once.

Extend apps you only installed in the Sandbox

Workday Extend apps move through tenants in a documented order: a Development tenant, then Implementation, then Sandbox, then Production, promoted one step at a time from the Developer Site and installed on each tenant through the Workday Extend App Manager worklet. That install record lives inside the tenant itself, the same as any other tenanted data, so it follows the same rule as everything else in this guide: an app installed only on the Sandbox, that hasn't been promoted up to and installed on Production, disappears from App Manager's Installed tab when the Sandbox refreshes.

Recovering it is mechanical, not destructive: promote the app to Sandbox again from the Developer Site's Promotions tab, then reinstall it from App Manager's Ready to Install tab. Once an app is installed on a non-Development tenant you can't remove it, but reinstalling after a refresh is expected, not an error. Reconfigure anything you'd set on the Configure screen, since that configuration was also tenanted and also came back as Production's copy.

Prepare before the refresh: inventory, then export

Start from the Configuration Change Tracker report to see exactly what changed in the Sandbox since you last migrated anything out of it. Anything in that list that only exists in the Sandbox is at risk on the next refresh.

For configuration you'll want to reload rather than rebuild, Workday's Configuration Extracts tool exists for exactly this: its own documentation describes using it when you need a copy of a configuration for reloading to your tenant at a later time, or to save a configuration before a tenant refresh. You can't load an extract straight into Production; move it through an Implementation or Sandbox tenant first, then use Object Transporter to carry it the rest of the way.

For work you'd rather not lose at all, migrate it out of the Sandbox before the refresh window instead of after. Object Transporter's documented migration paths list the Sandbox as a valid source tenant, with Implementation, another Sandbox, and Sandbox Preview as valid targets, so moving a build from Sandbox up to Implementation, which refreshes on demand rather than weekly, is a supported way to park it somewhere the weekly refresh won't reach.

Getting your configuration back after the refresh runs

If you exported with Configuration Extracts, reload the extract file into the freshly refreshed Sandbox. If you migrated the work to Implementation beforehand, run Object Transporter again from Implementation back into the Sandbox. Either way, treat the reload the same as any other cross-tenant migration: compare source and target before you commit, and reopen each object afterward to confirm what actually saved, rather than assuming the migration screen's confirmation is the proof. The guide on copying configuration between tenants covers that comparison and readback step in detail.

Reinstall any Extend app that dropped off the Sandbox's Installed tab, redo the SMS and email notification restrictions the refresh overwrote, and re-run any integration test that depended on a Sandbox-specific credential or endpoint you'd changed for testing. None of this is Workday malfunctioning; it's the refresh doing exactly what it's documented to do.

Where this connects

If you're not sure which of your tenants refreshes weekly versus on demand, or what separates a Sandbox from an Implementation tenant in the first place, see the guide to Workday's tenant types. For the errors that show up mid-deployment when an Extend app promotion doesn't land cleanly on a freshly refreshed tenant, see the Extend deploy errors guide.

kiweely can read a tenant back after a migration or a refresh and tell you what's actually there, in your words, without you having to reopen every object yourself; in a Production tenant it only makes a change after you say to, one at a time, with a readback before the next.

Sources checked