Workday Test Data: How to Build Realistic Data in a Sandbox or Implementation Tenant

Workday does not generate test data for you. Realistic test data in a Sandbox or Implementation tenant comes from one of three places: a copy of your Production data that Workday puts there on a refresh, records you create yourself by running real transactions or loading a file, or a Workday demonstration tenant that holds no customer data at all.

Which one fits depends on what you are testing. This page covers each source, what a refresh will wipe, and how to keep real people's data out of reach of testers.

Where does test data in a Workday tenant come from?

Workday's tenant datasheet describes the Sandbox as a weekly copy of Production data and configuration, and the Implementation tenant as a copy of customer data that is refreshed when you ask for it. The tenant types and the refresh schedule are covered in the tenant types guide and the Sandbox refresh guide.

For most business process testing the refreshed copy is the right base, because it already has your supervisory organizations, job profiles, locations and security. The work is adding the specific cases you need on top of it.

What does a refresh overwrite?

Everything that exists only in the non-Production tenant. A worker you hired in Sandbox for testing is gone after the next refresh, unless the same worker exists in Production. So are calculated fields, reports and security changes you built there and never moved up.

Plan for it:

• Write down the test cases (the hires, terminations, job changes and requisitions) as a script you can replay, not as records you hope will still be there on Monday.
• If a multi-week test cannot survive a weekly refresh, use an Implementation tenant, which Workday refreshes on demand.
• Before a refresh of a tenant that holds configuration you want to keep, Workday's Create Configuration Extract task (in Customer Central) saves a configuration package from a Sandbox or Implementation tenant so you can upload it to the same tenant afterward. That saves configuration. It does not save the test workers.

How do I keep test emails from reaching real people?

A refresh copies Production, including real email addresses, so a notification fired from a test event can reach a real person unless you restrict it. In Edit Tenant Setup - Notifications you can add a restriction that disables all email notifications, or redirects them to a contact or an email address you choose.

Workday's note on this setting is worth following literally. Make sure no campaigns or processes are running when you create or change a restriction in a non-Production tenant, because notifications being processed at that moment can still go to the real recipient. The documented way around it is to create the restriction in Production, naming the target environments, and then request a refresh to the non-Production tenant, so the restriction arrives with the copy. The same page says that after a refresh from Production the copied SMS configuration appears in the non-Production tenant and should be deleted.

Can I mask or scramble real data in a test tenant?

Partly, and only where Workday documents it. Workday has a Create Data Scramble Plan task, secured to the Scrambler Administration domain. Its documentation for compensation says you can scramble or remove compensation data in Implementation tenants for training and testing, or to cloak sensitive information. It warns that scrambling permanently changes or removes data and says to scramble in Implementation tenants only.

Workday's openly readable documentation covers scrambling for compensation data. Its broader data scrambling concept page sits behind a Workday sign-in, so check there, or with your Workday account team, what else your tenant can scramble before relying on it. If your policy forbids real personal data in testing, decide that before the refresh. The alternative is to test in a Development tenant or a demonstration tenant with sample data.

Should I load test workers with an EIB or hire them through the business process?

Both, for different reasons.

Hire through the business process when you are testing the process. The Hire Employee task runs the Hire business process with its real routing, conditions, approvals and downstream steps. It also enforces your real rules: the hire date has to be on or after the recruiting start date on the job requisition, or the earliest hire date on the position if you do not use requisitions, and many fields fill from the job profile, position or requisition. When you use job requisitions, those values cannot be changed on the hire. If a test case cannot be hired in cleanly, that is a finding about your configuration.

Load with an inbound EIB when you need volume and the business process is not what you are testing, for example a few hundred records to exercise a report or an integration. The documented pattern is:

1. Run Create EIB, mark it Inbound, and choose the web service operation for the data you are loading.
2. The operation must be enabled for inbound EIB use, and you need the Integration Build domain.
3. From the EIB's related actions, generate the spreadsheet template. Fill it in, using the same Spreadsheet Key on every row of one record and an incrementing ID for child rows.
4. For records that already exist, copy their IDs from Integration IDs, View IDs on the record.
5. Attach the filled spreadsheet and launch.

Know the limits before a large load. Files uploaded from a browser are limited to 30 MB, and the error and failure files Workday attaches to an inbound run are kept for 60 days. When a load finishes with errors, the EIB load errors guide shows how to read them. One caution that Workday's page does not settle: do not assume a load runs the same approvals as the matching business process. Check what actually happened to the records you loaded, and say in your test notes which route created each one.

How do I test with different roles once the data exists?

Create the cases for the roles the process involves, then sign in as each role through proxy. A manager who sees different data from an HR partner is the most common thing a single-user test misses. The multi-persona proxy testing guide walks through that sequence. For the whole chain from initiation to the downstream integration, see end-to-end testing in Workday.

What about test data for a Workday Extend app?

A Workday Cloud Platform Development tenant comes staged with data for a sample enterprise. Workday offers Global Modern Service (a global corporate company), Green Oak Valley (government) and Alma Mater University (higher education). Workday's own recommendation is to use only sample data in those tenants and never PII.

Extend developers also have a second option that needs no tenant data at all. In App Preview, mock data responses let you test inbound and outbound data on a page without connecting to a tenant. Workday lists two benefits: realistic sample JSON without changing source code, and protection against changing data in your tenant or an external system. Endpoints that use OAuth2 authentication require mock data, because tenant connection does not support them. Preview, mock data and a deployed app each prove different things, and the Extend testing guide explains when to use which.

If your Extend app stores records in its own business objects, Workday's data purge feature removes them permanently. Workday recommends testing a purge in Sandbox first, building the custom report that selects the records before you purge, running it before and after to compare, and keeping each purge to 25,000 instances or fewer.

When kiweely builds an Extend app, it exercises the deployed pages in a browser and reads the saved records back from your tenant, so a test checks stored data rather than only a mock.