Four tenants Workday defines, plus one that isn't a tenant at all
Every Workday customer is entitled to a Production tenant, a Sandbox tenant, and a Sandbox Preview tenant as part of a core subscription. Most customers also buy one or more Implementation tenants, priced and provisioned separately, for work that doesn't belong in any of the entitled three. A fifth item, Customer Central, gets called a tenant in casual conversation but Workday's own datasheet is explicit that it isn't one: it's a management tool, a single pane of glass over the tenants you actually have, used for things like single sign-on configuration.
Workday also provisions demonstration tenants (GMS for general company data, GOV for government, AMU for education) pre-loaded with synthetic data for training and product exploration. They don't hold your data and aren't part of a deployment, so the rest of this guide is about the four that are.
Production: the system of record, nothing else
Production is where your organization's live, active data lives, and Workday's own materials call it the customer's system of record. Every other tenant type exists so that configuration, testing, and training happen somewhere other than here. Build and test elsewhere; use Production to run the business and to hold the configuration you've already proven works.
Sandbox: a weekly copy of Production, for anything that could go wrong
The Sandbox tenant is created once your Production tenant goes live, and Workday refreshes it weekly with a full copy of Production, data and configuration together, to keep it in line with the current deployment. It's a safe replication of Production for any activity that could alter the tenant in ways you don't intend to commit for real, and Workday Support often works in this environment when helping you solve a problem.
The weekly refresh is the tradeoff: it keeps the Sandbox current, but it also erases anything you built there and didn't migrate out first. The Sandbox refresh guide covers exactly what that refresh wipes and how to get configuration back afterward.
Sandbox Preview: the same copy, plus next release's features
Sandbox Preview is also a mirror of Production, but Workday layers in functionality from the upcoming feature release before that release reaches any other tenant. Feature releases ship twice a year, and Workday delivers the new functionality to preview tenants roughly five weeks ahead of the release, so you can see what's coming, test it, and verify integrations before it goes live everywhere at once on release day. Run the What's New in Workday report in Sandbox Preview once the release preparation period begins, and again as needed through the preview window, to see what's changing.
Workday refreshes Sandbox Preview twice a year rather than weekly, on its own cycle tied to the release calendar, not to the Sandbox tenant's schedule.
Implementation: a replica you control the refresh timing on
An Implementation tenant is a direct replica of Production, but Workday refreshes it on demand instead of on a fixed schedule, which is the whole point of buying one: it gives you flexibility the entitled tenants don't. Customers typically run four to ten or more active Implementation tenants at once, used for scenario modeling around a merger or divestiture, testing a new feature or integration before it reaches Production, loading legacy data, and running unit or end-to-end testing that needs more time than a week between refreshes.
An Implementation tenant that's approaching go-live and will become the new Production tenant is what Workday calls a GOLD tenant. If you plan to use an Extend app immediately once that Production tenant exists, its source has to be promoted to Production at least a week before the GOLD tenant converts; miss that cutoff and Workday can't make an exception, and the app's tenanted data can end up with orphaned security policies, missing functional areas, or broken business process definitions that have to be manually recreated.
Where to build, test, and train
| Task | Tenant |
|---|---|
| First build of new configuration or an Extend app | Implementation (or a Development tenant for Extend apps, before Implementation) |
| Anything destructive or exploratory you might need to redo weekly | Sandbox |
| Checking a feature release before it reaches everyone | Sandbox Preview |
| Legacy data loads, M&A scenario modeling, long-running UAT | Implementation |
| Running the business, and configuration already proven elsewhere | Production |
Never build untested configuration directly in Production, and never treat a business process change, a security policy edit, or an integration cutover as low-risk there just because it seemed to work in the Sandbox: the Sandbox is a full copy, but its weekly refresh means whatever you're looking at might not be what you tested last week.
Comparison
| Tenant | Contains | Refresh | Gets next release |
|---|---|---|---|
| Production | Live customer data, system of record | Never (it's the source) | On release day, with everyone else |
| Sandbox | Full copy of Production | Weekly | On release day, with everyone else |
| Sandbox Preview | Full copy of Production | Twice a year, on the release cycle | ~5 weeks early |
| Implementation | Direct replica of Production | On demand | On release day, with everyone else |
Telling your tenants apart
Workday doesn't enforce a naming convention across tenant types; the name you see at sign-in and in the URL is whatever your organization chose when the tenant was provisioned, so don't assume a suffix like "sandbox" or "impl" in a tenant's name means anything beyond what your own team decided it should. Many organizations use the Configure Tenant Branding and Edit Tenant Setup - System tasks to set a distinct logo, banner, or color per tenant specifically so people can tell them apart at a glance; if your tenants aren't branded this way, Customer Central's single view of your whole deployment is the reliable place to confirm which tenant is which.
Where this connects
Once you know which tenant you're in, the next question is usually what a refresh does to it: see the guide to what a Sandbox refresh wipes. For why Production gets treated differently from every other tenant on this list, including in how changes get made there, see the trust layer behind a Production tenant.
kiweely keeps each client's tenants separate by design, and treats a Production tenant with the stricter rhythm this guide describes: changes there happen one at a time, read back before the next, only with the person's consent.