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.

SAP SuccessFactors Workday integration

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.