Testing a Workday business process in Sandbox is rarely a single-user task. A routine compensation change, promotion, or job requisition spans an entire chain of actors: the initiating employee, the direct manager, the compensation partner, and the HR director.

When testing fails during User Acceptance Testing (UAT), the root cause is almost never that the form could not be submitted. It is that a step routed to the wrong inbox, skipped an approval tier because of an untested condition rule, or failed to write back an effective date.

This guide outlines a repeatable methodology for multi-persona proxy testing in non-production tenants to verify the entire routing chain before releasing changes.

1. Map the Expected Approval and Review Chain

Before initiating any test transaction in Sandbox, document the exact chain of participants in a testing matrix:

  1. Initiator (Worker / Self-Service): Who kicks off the business process event?
  2. First-Line Reviewer (Manager / Lead): What condition rule routes the event to them, and what fields are they permitted to edit versus review?
  3. Functional Partner (HR Partner / Compensation Partner): Does the step route based on the worker's supervisory organization, company, or cost center?
  4. Final Approval (Executive / VP): Is there an approval threshold rule (for example, salary increases above 10% or requisitions above a specific headcount tier)?

For each step, record three expected states:

  • The assigned inbox: Which specific worker or role should see the task in their Workday Inbox?
  • Action type: Approval, Review, To Do, or Consolidated Approval?
  • Downstream data mutation: What fields should update upon step completion?

2. Prepare Representative Personas in Sandbox

Do not test with random worker accounts. Prepare a clean set of synthetic test personas in Sandbox that represent real organizational hierarchies:

  • Worker Persona: A standard active employee assigned to a defined Supervisory Organization with an assigned Manager.
  • Manager Persona: The direct manager holding the management position on that Supervisory Organization.
  • Role-Based Partner Persona: A user assigned the relevant partner role (such as HR Partner or Compensation Partner) on the test Supervisory Organization or its parent organization.
  • Secondary / Matrix Manager (if applicable): To test matrix management or dotted-line approvals.

Pre-Flight Account Checks

Before starting the test run:

  • Verify that all test personas are active and have valid business titles and organizations.
  • Confirm that none of the test personas have active delegation rules configured (Manage Delegations) that would reroute tasks unexpectedly.
  • Confirm that proxy access is authorized for your administrative account (Start Proxy security policy in the non-production tenant).

3. Execute the Step-by-Step Proxy Chain

Follow the transaction through every handoff without skipping steps or manually advancing events in the administrative console.

Step 1: Initiate as the Worker

  1. In the search bar, type Start Proxy and select the Initiator persona.
  2. Navigate to the relevant task (for example, Request Compensation Change or Create Job Requisition).
  3. Fill in all required fields, including any edge-case values you need to evaluate (such as exceeding a pay range or choosing an unusual effective date).
  4. Click Submit.
  5. Note the Process Successfully Submitted confirmation banner and click View Details.
  6. Note the exact Event Title and the current status: Awaiting Action. Note which worker or security group is listed under the next step.
  7. In the search bar, type Stop Proxy to return to your administrative session.

Step 2: Review and Approve as the Manager

  1. Type Start Proxy and select the Manager persona identified in the previous step.
  2. Open the Inbox (My Tasks).
  3. Locate the pending task. Verify that the task title and worker details match what was submitted.
  4. Verify field permissions: can the manager see sensitive fields that should be hidden, or edit fields that should be read-only?
  5. Select Approve (or enter comments and approve).
  6. Note the next assigned recipient displayed on the confirmation screen.
  7. Type Stop Proxy.

Step 3: Action by the Functional Partner

  1. Type Start Proxy and select the Partner persona (for example, HR Partner).
  2. Open the Inbox and select the event.
  3. If this step is a Review step, test an adjustment: change a proposed date or compensation component and confirm that the change saves properly.
  4. Complete the task.
  5. If the business process definition contains child processes (such as Propose Compensation Hire nested inside Hire), confirm that the sub-process triggers and completes in sequence.
  6. Type Stop Proxy.

4. Verify Final State and Data Writebacks

Never assume a process is successful simply because the inbox emptied. Always verify the data at the source:

  1. As an administrative user or the target worker, search for the target worker profile.
  2. Open the relevant profile tab (such as Compensation, Job History, or Organizations).
  3. Confirm that the effective date matches the test scenario.
  4. Verify that historical records are preserved and the new values reflect the approved numbers.
  5. Search for the event title in the global search bar and open the Process History tab:
    • Confirm that every step evaluated in sequence.
    • Confirm that no unexpected condition rules caused steps to evaluate as Not Applicable when they should have fired.
    • Check the execution timestamps to ensure automated background steps finished without errors.

5. Common Multi-Persona Testing Pitfalls

  • Self-Approval Suppression: If an initiator also holds an approval role in the hierarchy, Workday's business process policy may auto-approve or route around them. Test with distinct individuals for each role to avoid false positives.
  • Inherited vs. Direct Role Assignments: If a partner step routes to an unexpected person, check whether the Supervisory Organization inherits the role from a parent organization or has a local assignment override.
  • Stale Sandbox Cache: If you recently altered a condition rule or business process definition, start a new transaction from scratch. Changes to business process definitions do not retroactively apply to in-flight events.

Sources checked