# SAP SuccessFactors Workday integration

*SAP SuccessFactors → Workday*

**In short:** A SAP SuccessFactors Workday integration keeps worker master data, organisational assignments, positions, and compensation aligned between SAP SuccessFactors Employee Central and Workday - usually with one system as the HR system of record. Done properly it reads effective-dated records from Employee Central over its OData API, matches each worker by a stable external ID, and applies hires, job changes, and terminations into Workday as staffing events in the right sequence and on the right effective date. It is not a nightly CSV: it is an idempotent pipeline that respects both systems' effective-dating and never double-books a transaction.

## What a SAP SuccessFactors to Workday integration actually does

SAP SuccessFactors Employee Central and Workday are both full HCM suites, so a company running both is almost never running them for the same reason. Usually one is the HR system of record - it owns the worker, the org structure, the job and pay - and the other needs that data to do its own job: run payroll, feed finance and cost-centre reporting, drive workforce planning, or carry talent and learning while the core sits elsewhere.

The integration keeps those two pictures of the same workforce aligned. When someone is hired, changes manager, moves cost centre, gets a pay rise, or leaves in the system of record, the other system has to reflect it - on the correct effective date, against the correct organisation, without anyone re-keying a personnel file. That is the job: not a one-off migration, but a continuous, effective-dated sync between two systems that both think in terms of dated history.

## What data moves

Typical direction shown below is SAP SuccessFactors Employee Central as system of record into Workday. The same pipeline runs the reverse or a coexistence split when your operating model calls for it.

| SAP SuccessFactors object / event | Becomes in Workday | Notes |
| --- | --- | --- |
| New hire (Employment Info) | Hire staffing event | Sequenced after the target position and supervisory org exist |
| Personal & biographical data | Worker personal data | National ID, name, contact mapped per country rules |
| Job Information change | Job Change / transfer event | Effective-dated; manager, position, cost centre carried across |
| Organisational assignment | Supervisory org + cost centre assignment | Foundation Objects mapped to Workday reference IDs |
| Compensation Info | Compensation / pay change | Pay component and currency mapped; grade and plan aligned |
| Termination / retirement | Terminate event | Booked on the exact effective date, reason code mapped |
| Foundation Objects / MDF (positions, legal entities) | Positions, org, cost centre reference data | Synced ahead of worker records |

The exact field maps, picklist-to-reference-ID translations, and the authoritative source per domain are agreed once and encoded in the pipeline. After that nobody reconciles a spreadsheet of employee IDs by hand.

## The details that break naive syncs

A nightly report drop or a generic connector gets the easy 80% and leaves the expensive, error-prone 20% on your HR team:

- **Effective-dating on both sides.** Employee Central records carry a start date; Workday books events as of an effective date. A change made today can be effective last month or next month. Sync on the wrong date and someone's pay, tax, or reporting line is wrong for a whole period. Retroactive and future-dated changes both have to be preserved, not flattened to "now".
- **ID matching.** A worker is `personIdExternal` and `userId` in SuccessFactors and an Employee ID plus an internal WID in Workday. There is no shared key by default. Every worker needs a stable, agreed match key, and rehires and concurrent employment must not create a duplicate or collide with a closed record.
- **Foundation data first.** A Workday hire fails if the position, supervisory org, or cost centre it references does not exist yet. Foundation Objects and MDF picklists have to be mapped to Workday reference IDs and synced ahead of the people, in dependency order.
- **Sequencing within a worker.** Hire before job change before compensation before termination. Events applied out of order leave Workday in a state Employee Central never described.
- **Two very different APIs.** Employee Central is OData v2 with `$skip`/`$top` paging and delta on `lastModifiedDateTime`; Workday is SOAP web services plus RaaS reports with its own paging and version lifecycle. Rate limits, page sizes, and retry semantics differ, and both retire API versions on a schedule.
- **Partial failures.** When one worker in a batch of 500 is rejected - a bad cost centre, a missing prerequisite - the other 499 must still land, and the failure has to be visible and replayable rather than silently swallowed.

## How we build and run it

We treat this as a pipeline, not a scheduled export. Changed records are pulled from the system of record on a schedule (or triggered), matched by their agreed key, mapped into the target system's model, sequenced correctly, and applied as staffing and compensation events on the right effective dates.

The pipeline is idempotent: every worker event carries a stable identifier and effective date, so a retry or a re-run after an outage never double-books a hire or a pay change. It runs on cloud-native, fully EU-hosted AWS infrastructure, so worker personal data never leaves the EU - which keeps your DPA / AVV and GDPR obligations clean for what is, by definition, sensitive HR data.

And then we keep it running. Monitoring, alerting, incident response, and - critically - tracking SAP SuccessFactors and Workday API version changes are our responsibility under contract. When Workday sunsets a WWS version or SuccessFactors changes an OData entity, we migrate it before it breaks payroll, not after.

## When this integration is worth building

If you are moving off one system onto the other and never running both in production, this is a migration project, not an integration - a point tool or a one-time load is the right answer, and we will tell you so. The pipeline earns its place when both systems run in parallel for the long term: one owning HR, the other owning payroll, finance, or planning, with people, orgs, and pay changing every day. Once the cost of a missed effective date is a wrong payslip or a broken cost-centre report, a managed, monitored pipeline is cheaper than the reconciliation it replaces.

## Frequently asked questions

### Which system is the system of record - SAP SuccessFactors or Workday?

Whichever your HR operating model says it is, and we build for that direction. The common pattern is SAP SuccessFactors Employee Central as the HR system of record feeding worker and org data into Workday for payroll, finance, or planning. We also build the reverse, and coexistence flows during a migration where both run in parallel. We agree the authoritative source per data domain up front so no field has two owners fighting over it.

### How do you connect to each system technically?

SAP SuccessFactors Employee Central is read and written over its OData v2 API with effective-dated entities and delta queries on lastModifiedDateTime. Workday we integrate through its web services - Staffing and Human Resources WWS for transactions - and RaaS report-as-a-service endpoints for bulk extracts. We handle the SOAP, the OData paging, and the authentication for both so your teams never touch either API surface.

### How is effective-dating handled between the two systems?

Both SAP SuccessFactors and Workday are effective-dated, and that is the hardest part of the pair. A change to a worker in Employee Central carries a start date; Workday needs the matching staffing event booked with the correct effective date, not the sync date. We preserve the effective date end to end and handle retroactive changes and future-dated records so history stays correct on both sides.

### Can it sync org and foundation data, not just employees?

Yes, and it usually has to. A worker assignment in Workday is meaningless without the supervisory organisation, position, cost centre, and legal entity it points at. We map SAP SuccessFactors Foundation Objects and MDF picklists to the equivalent Workday reference IDs, and sequence foundation data ahead of worker records so every assignment lands against an org that already exists.

### Who operates it after go-live, and where does the data run?

We do. The pipeline runs on cloud-native, fully EU-hosted infrastructure that we monitor, with worker personal data never leaving the EU. If SAP or Workday changes an API version - and both retire versions on a schedule - that is our problem to fix under contract, not something your HR team discovers when payroll runs. You get a named owner, alerting, incident response, and an SLA.

## Related integrations

- [BambooHR ↔ Workday](https://seamless.engineering/integrations/bamboohr-workday/): BambooHR Workday integration
- [Personio ↔ Workday](https://seamless.engineering/integrations/personio-workday/): Personio Workday integration
- [Workday ↔ ServiceNow](https://seamless.engineering/integrations/workday-servicenow/): Workday ServiceNow integration
- [Greenhouse ↔ Workday](https://seamless.engineering/integrations/greenhouse-workday/): Greenhouse Workday integration
- [SmartRecruiters ↔ SAP SuccessFactors](https://seamless.engineering/integrations/smartrecruiters-successfactors/): SmartRecruiters SAP SuccessFactors integration
- [Factorial ↔ DATEV](https://seamless.engineering/integrations/factorial-datev/): Factorial DATEV integration

## Browse by system

- [All SAP integrations](https://seamless.engineering/integrations/sap/)
- [All Workday integrations](https://seamless.engineering/integrations/workday/)

## Request a scoping call

Need this integration built and permanently operated? Tell us which systems connect and what data has to move. Fixed-price scoping quote within 48 hours.

- Email: hello@seamless.engineering
- Contact form: https://seamless.engineering/#contact