Salesforce to Workday Testing
Salesforce to Workday testing validates the business processes that depend on the two systems agreeing — a hire in Workday becoming a correctly provisioned Salesforce user, an organization or cost center change reaching territories and reporting, a termination removing access on time, and, where Workday Financials is used, customer and billing data flowing from closed deals. It proves that people and financial data stay consistent across both platforms.
Cross-application journeys, including Salesforce and Workday, are on the active roadmap and available for proof-of-concept engagements.
The processes that connect Salesforce and Workday
Workday is the system of record for workers, positions, supervisory organizations and cost centers. Salesforce needs that information to decide who can log in, which role and territory a user belongs to, who their manager is for approvals and forecasting, and which cost center their activity reports into. The most common integration therefore runs from Workday to Salesforce: hire, transfer, manager change and termination events creating, updating or freezing Salesforce users and their assignments.
A second pattern runs the other way for organizations using Workday Financials or Workday professional services automation. A closed-won opportunity or signed contract in Salesforce creates or updates a Workday customer, customer contract or project, so billing and revenue recognition can begin. Integrations are typically built with Workday web services and reports-as-a-service, Workday Studio or Enterprise Interface Builder, or middleware such as MuleSoft, and they often run on a schedule rather than in real time.
Because these flows affect access, approvals and revenue, they are best tested as business processes with defined outcomes. The interface mechanics are covered by Salesforce to Workday integration testing; this page focuses on the end-to-end journeys.
Workday events and the Salesforce outcomes to prove
Each Workday business process should produce a specific, checkable result in Salesforce. These are typical mappings; each organization's design will vary.
| Workday event | Expected Salesforce outcome | Key assertion |
|---|---|---|
| Hire into a sales position | User created with profile, permission sets, role and territory derived from job profile and organization | User can log in only from the effective date, with no default or elevated access |
| Transfer to a new organization | Role, territory, public groups and queue membership updated | Access to the old team's records is removed as designed |
| Manager change | User ManagerId updated | Approvals and forecast hierarchy follow the new manager |
| Cost center change | Cost center or department field updated on the user | Reports and commissions attribute activity to the new cost center |
| Termination | User frozen or deactivated on the termination date; records reassigned | No login after the effective time; owned opportunities and cases have an active owner |
| Rehire | Existing user reactivated rather than duplicated | Federation ID and username reused as designed |
| Closed-won deal (Financials) | Workday customer and customer contract created or updated | Contract lines, amounts and dates match the Salesforce deal |
Where people and finance data drift
Drift between Workday and Salesforce is often invisible until an access review, a commission dispute or a billing delay exposes it.
Late deprovisioning
A scheduled integration runs nightly, so a terminated employee keeps Salesforce access for hours — or days, if a run fails without alerting anyone.
Role mapping gaps
A new Workday job profile has no mapping to a Salesforce profile or permission set group, and the user is created with a fallback that grants too much or too little.
Broken manager chains
A manager's own position change is processed after their reports, leaving approvals routed to an inactive user.
Effective-date handling
Future-dated hires and transfers are applied immediately, or backdated changes are ignored, because the integration reads only current values.
Testing the joiner-mover-leaver journey
SyntraFlow is designed to follow a worker's lifecycle across both systems, initiating business processes in a Workday test tenant and asserting the result in Salesforce.
Hire the worker in Workday
Complete a hire into a sales position with a known job profile, supervisory organization, cost center and effective date, using test tenant data.
Run or await the integration
Trigger the scheduled integration where permitted, or wait for its run, and capture the integration event status on the Workday side.
Assert the Salesforce user
Confirm the user's profile, permission sets, role, territory, manager, cost center, Federation ID and active status match the mapping rules.
Transfer and change manager
Process a transfer in Workday and confirm role, territory, queues and manager update in Salesforce, and that access follows the new assignment.
Terminate
Process a termination and confirm the user is frozen or deactivated at the effective time and that owned records are reassigned as designed.
Reconcile the population
Compare active Workday workers in scope with active Salesforce users to confirm no orphaned or missing accounts remain.
Exception paths worth exercising
These scenarios reflect how people data actually changes, rather than the clean cases used during implementation.
- A future-dated hire, confirming the Salesforce user is not active before the start date.
- A rescinded hire or cancelled transfer, confirming Salesforce changes are reversed.
- A termination for a user who owns open opportunities, cases and approval requests, confirming nothing is left with an inactive owner.
- A job profile with no mapping, confirming the integration fails safely and alerts rather than applying a default profile.
- Salesforce license exhaustion during a hire wave, confirming the failure is reported.
- A worker with a changed legal name or email, confirming username and Federation ID rules prevent duplicate users.
- A failed integration run followed by recovery, confirming changes from the missed run are applied in effective-date order.
Security, roles and test data
This process is as much a security control as a data flow. Auditors often ask for evidence that leavers lose access promptly and that new users receive only the access their job requires. Testing the joiner-mover-leaver journey end to end produces that evidence and complements permission set testing and segregation of duties checks. The integration user itself should also hold only the Salesforce permissions it needs to manage users, which integration user testing addresses.
Test data should be synthetic workers created in a Workday implementation or sandbox tenant, never copies of real employee records, and should span the job profiles, organizations, countries and worker types in scope. Salesforce sandbox users created by runs need to be tracked and cleaned up, and license availability in the sandbox should be checked before a run. Guidance on keeping personal data out of test environments is covered by data masking.
Suggested test scenarios
A representative set covering people data and, where used, the financial handoff.
| Scenario | What it proves | Expected result |
|---|---|---|
| Sales hire | Joiner provisioning follows mapping rules | Active user with the mapped profile, role and territory |
| Organization transfer | Mover access is adjusted | New team access granted; old access removed |
| Termination with owned records | Leaver access and ownership handled | User frozen or deactivated; records reassigned |
| Future-dated hire | Effective dates are respected | No active user before start date |
| Unmapped job profile | Safe failure on missing mapping | No user created; alert raised |
| Population reconciliation | No orphaned or missing accounts | In-scope Workday workers equal active Salesforce users |
| Closed-won to Workday contract | Financial handoff is accurate | Customer contract lines and amounts match the deal |
Evidence and SyntraFlow's Workday depth
A complete run is designed to capture the Workday business process and effective dates, the integration event outcome, the resulting Salesforce user or record state, and a reconciliation across the population in scope. Security, HR systems and Salesforce teams can each use the same evidence.
Workday releases twice a year and Salesforce three times, and both can change what the integration reads or writes. SyntraFlow's existing Workday testing capability gives it a view of the Workday side of these journeys, so a single scenario can be designed to assert on both systems rather than stopping at the boundary.
Related pages
Business Processes
The full library of Salesforce business process tests this journey belongs to.
Salesforce to Workday Integration Testing
The interface and middleware mechanics behind these processes.
Workday Testing
SyntraFlow's Workday-side testing that supports both-ends assertions.
Integration User Testing
Least-privilege checks for the user that provisions and updates Salesforce users.
Permission Set Testing
Proves the access each mapped job profile receives in Salesforce.
Cross-System Test Data
Coordinating synthetic workers and Salesforce users across both platforms.
Salesforce → Workday testing FAQs
What is Salesforce to Workday testing?
It is testing the business processes that depend on Salesforce and Workday sharing data — most often worker hires, transfers and terminations provisioning Salesforce users, and in some organizations Salesforce deals creating Workday customers, contracts or projects. Tests trigger events on one side and assert the outcome on the other.
Why test user provisioning end to end instead of just the integration?
The business outcome is access: who can log in, with what permissions, and when that access ends. An integration can report success while mapping a user to the wrong profile or deactivating them late. Asserting the Salesforce user state after a Workday event proves the control actually works.
How are effective dates tested?
Scenarios include future-dated hires, backdated changes and rescinded events, with assertions on Salesforce state before and after the effective date. This confirms the integration respects Workday's effective-dated model rather than applying every change immediately.
Can real employee data be used for these tests?
It should not be. Synthetic workers in a Workday non-production tenant, covering the job profiles and organizations in scope, give realistic coverage without exposing personal data. Any production-derived data should be masked before use in test environments.
Does SyntraFlow build the Salesforce to Workday integration?
No. SyntraFlow is designed to test existing integrations by their result. Its Workday testing capability means it can be configured to act on and read the Workday side of a scenario, alongside Salesforce, using access the customer provides.
Is Salesforce to Workday testing available in SyntraFlow today?
Cross-application journeys, including Salesforce and Workday, are on the active roadmap and available for proof-of-concept engagements. The flows, tenants and scenarios in scope are confirmed per engagement.
Keep Salesforce access in step with Workday
Map your joiner, mover and leaver flows and see how both systems can be asserted in a single scenario.