Salesforce–Workday Integration Testing
Salesforce–Workday integration testing validates the worker, organization and job data that flows between Workday and Salesforce — hires that create users and service resources, transfers that change managers, territories and permissions, and terminations that must remove access on time. SyntraFlow is designed to validate both ends of each flow and reconcile them, so what Salesforce grants always reflects what Workday says is true.
Salesforce–Workday validation is available for demonstration and proof-of-concept validation. SyntraFlow does not claim a certified Workday connector.
Why the Workday boundary matters
In most organizations Workday is the system of record for people. Salesforce depends on that data more than it first appears: user records and their managers, roles and permission set assignments, sales territories and quota owners, Field Service resources and their skills and locations, professional services resources and their cost rates, and, where Employee or Work.com objects are used, employee records for internal service. When a worker is hired, moves or leaves in Workday, several things in Salesforce are supposed to change.
The risks are different from an ERP integration. A late or missed update is not only a data quality issue — it is an access issue. A terminated employee who stays active in Salesforce keeps access to customer data. A transfer that updates the manager but not the role hierarchy silently changes record visibility. Effective dating in Workday means a change can be entered today but take effect next month, and the integration has to act on the right date.
This page covers the integration layer between the two systems. For the end-to-end business process, see Salesforce to Workday testing; for testing Workday itself, see Workday testing.
What to validate on each side
Each worker event in Workday should produce a defined result in Salesforce. The fields involved are confirmed per implementation.
| Worker event or data | Validate in Workday | Validate in Salesforce |
|---|---|---|
| New hire | Worker, position, job profile, supervisory organization, location and effective date | User created or activated with the right profile, role, manager, permission sets and federation ID |
| Service or project resource | Job profile, skills or qualifications, location and cost center | Service resource, skills, territory membership or resource record created and active |
| Manager change | New supervisory organization and manager | Manager field and role hierarchy updated, so approvals and sharing follow the change |
| Transfer or job change | New position, job profile, cost center and effective date | Profile, permission sets, territories and queues adjusted on the effective date |
| Leave of absence | Leave type, start and expected return dates | Resource availability or absences reflected; access retained or suspended per policy |
| Termination | Termination date and reason | User frozen or deactivated, records reassigned, resources inactive, licenses released |
| Rehire | Rehire event linked to the prior worker ID | Existing user reactivated rather than a duplicate user created |
| Organization and cost center changes | Organization hierarchy and cost center assignments | Mapped department, division or custom fields updated consistently |
A two-sided Workday to Salesforce test
SyntraFlow can be configured to follow a worker event from Workday into Salesforce and assert on data and access together.
Select or prepare a test worker
A worker in a Workday test tenant is chosen or prepared with a known position, organization and manager, using masked data where production copies are involved — see data masking.
Complete the worker event
The hire, transfer or termination is completed in Workday with a defined effective date, including a future-dated variant where the process allows it.
Run or await the integration
The integration runs through its real mechanism — a scheduled extract, a report-based feed, Workday web services called by middleware, or an identity provider in between — and the test waits for Salesforce to update.
Assert the Salesforce records
User, service resource or employee records are checked field by field against the Workday values, including manager, role and federation identifiers.
Assert effective access
Permission set assignments, role, queue and territory membership are checked, and record visibility is confirmed by querying as the user, so the access outcome is proven, not inferred.
Confirm effective dating
A future-dated change must not apply early, and must apply on or shortly after its effective date according to the integration schedule.
Reconcile the population
Active Salesforce users in scope are compared with active Workday workers, flagging leavers still active and joiners never provisioned.
Common Salesforce–Workday defects
These defects recur in HR-driven integrations and are often found by auditors rather than testers.
Leavers still active
A termination fails to deactivate or freeze the Salesforce user, often because the user owns records or is referenced in a process that blocks deactivation.
Duplicate users on rehire
A rehired worker receives a new username instead of reactivating the existing user, splitting ownership history.
Stale manager and role
The manager field updates but the role does not, so the new manager cannot see the team's records and the old manager still can.
Premature future-dated changes
An integration that ignores effective dates applies a transfer or termination before it is due.
Permission accumulation
Transfers add new permission sets without removing old ones, so long-serving workers collect access they no longer need.
Unmapped organizations
A new supervisory organization or cost center in Workday has no Salesforce mapping, and affected workers fail silently or receive defaults.
Access checks worth including
Because Workday data drives Salesforce access, security assertions belong in every worker-event scenario.
- The profile and permission set groups assigned on hire match the job profile mapping, validated with permission set testing.
- The role assigned places the user correctly in the hierarchy, confirmed with role hierarchy testing.
- A terminated user cannot log in and holds no active sessions or OAuth tokens after deactivation or freezing.
- Records and open work owned by a leaver are reassigned according to policy, so cases and opportunities are not orphaned.
- Access that conflicts with a worker's new job after a transfer is removed, supporting segregation of duties controls.
- The integration user that performs provisioning has only the user-management permissions it needs.
Where SyntraFlow fits
SyntraFlow is designed to validate both ends of a Salesforce–Workday integration: the worker event and data in Workday, and the users, resources and access that result in Salesforce. That two-sided view matters because HR-driven defects are rarely visible from one system alone. SyntraFlow does not claim a certified Workday connector, and the interfaces used to read Workday data are agreed for each tenant during scoping.
A practical starting point is the joiner, mover and leaver trio for one population, such as sales users or field technicians, validated as a proof of concept against a Workday test tenant and a Salesforce sandbox. Those scenarios then become regression for Workday feature releases, Salesforce seasonal releases and mapping changes. Failure handling, such as a provisioning run that stops part way through, is covered by integration error and recovery testing, and population-level comparison by data reconciliation testing.
Evidence for access reviews and audits
Joiner, mover and leaver controls are routinely audited, and two-sided test runs can supply the evidence.
| Control | Evidence a test run provides |
|---|---|
| Timely deprovisioning | Termination effective date in Workday against the deactivation time in Salesforce |
| Appropriate access on hire | Job profile in Workday against assigned profile, role and permission sets |
| Access adjusted on transfer | Before and after permission comparison for moved workers |
| Complete population | Reconciliation of active workers and active users in scope |
| No duplicate identities | Rehire scenarios showing a single reactivated user |
Related pages
Salesforce Integration Testing
The parent hub for APIs, events, middleware and cross-system validation.
Salesforce to Workday Testing
The end-to-end business process spanning both systems.
Workday Testing
Testing Workday business processes and releases in their own right.
Permission Set Testing
Prove the access granted from Workday job data is correct.
Data Reconciliation Testing
Compare active workers and active users across both systems.
Data Masking
Protect personal worker data used in test tenants and sandboxes.
Salesforce–Workday Testing testing FAQs
What is Salesforce–Workday integration testing?
Salesforce–Workday integration testing validates the worker, organization and job data that flows between Workday and Salesforce. It confirms that hires, transfers, leaves and terminations in Workday produce the correct users, resources and access in Salesforce on the right effective dates, and reconciles the two systems.
Does SyntraFlow have a certified Workday connector?
No. SyntraFlow is designed to validate both ends of a Salesforce–Workday integration, reading Workday data through the interfaces agreed for each tenant. It does not claim Workday certification. Capabilities are available for demonstration and proof-of-concept validation.
Why test access, not just user fields?
Workday data usually drives who can see and do what in Salesforce. A user record can look correct while the role, permission sets or territory membership are wrong. Checking effective access, including record visibility for the user, proves the business and compliance outcome rather than just the data sync.
How are future-dated Workday changes tested?
Complete a transfer or termination with a future effective date, then confirm Salesforce does not change before that date and does change on or shortly after it, according to the integration schedule. Both halves matter: applying early and applying late are separate defects.
Why do Salesforce user deactivations fail?
Salesforce can block deactivation when a user is referenced elsewhere, for example as a default workflow user, in certain approval or automation settings, or in some managed package configuration. Integrations often freeze the user instead. Tests should confirm leavers are frozen or deactivated and cannot log in, whichever approach is used.
How is this different from the Salesforce to Workday business process page?
The business process page follows a request or process from a business user's perspective across both systems. This page focuses on the integration layer — the worker data, mappings, effective dating and resulting access — and on the defects and evidence specific to HR-driven provisioning.
Keep Salesforce access in step with Workday
See how SyntraFlow is designed to validate joiners, movers and leavers on both sides and reconcile users against workers.