Which direction does the data flow, and can it be both?

The primary flow is SmartRecruiters to SAP SuccessFactors: a hired candidate becomes a new hire in Employee Central or an onboardee in Onboarding 2.0. Many customers also want the reverse: approved requisitions and positions flow from SuccessFactors into SmartRecruiters so recruiters never re-key job data. We build whichever directions you need and keep them consistent.

Do you write into Employee Central directly or into Onboarding 2.0?

Both are valid targets and they behave differently. Employee Central expects an effective-dated new hire built from composite entities like PerPerson, EmpEmployment, and EmpJob. Onboarding 2.0 expects an onboardee that later converts to an EC employee. We agree the target with your HR-IT team up front, because it changes how identity, start-date changes, and rehires are handled.

How do you stop a rehire from creating a duplicate person?

SuccessFactors keys people on a stable person identifier (person-id-external), and a rehire must attach to the existing person rather than mint a new one. We match incoming hires against existing records using the identifiers you designate - national ID, email, or a prior person id - and route confirmed rehires to an update flow instead of a fresh insert. This is the single most common failure in naive exports.

What happens when the offer start date changes after we have already exported the hire?

The pipeline treats the export as an update, not a one-shot insert. Because every SmartRecruiters hire carries a stable key, a changed start date, title, or location produces a corrected effective-dated record in SuccessFactors rather than a second employee. Late offer changes are normal in recruiting, so the integration is built to expect them.

Is candidate data safe under GDPR, and how do you handle the works council?

The pipeline runs on cloud-native, fully EU-hosted infrastructure, so candidate and employee data never leaves the EU. We work under a DPA/AVV and can scope exactly which fields cross the boundary and when, which matters when a works council (Betriebsrat) needs to approve what recruiting data lands in the HR system of record. The data flow is documented rather than hidden inside a plugin.

SmartRecruiters SAP SuccessFactors integration

What a SmartRecruiters to SAP SuccessFactors integration actually does

SmartRecruiters knows everything about how someone got hired - the requisition they applied to, the offer that was approved, the start date, the location, the resume, the signed offer letter. SAP SuccessFactors needs that same person to appear as a structured employee: attached to the right legal entity, position, and cost center, with a valid start date and every field mapped to a code the HR system actually recognises.

The gap between “candidate marked Hired” and “employee live in Employee Central” is where the manual work lives today - HR re-keying names, start dates, and org assignments from one screen into another, then chasing the mistakes. A SmartRecruiters to SAP SuccessFactors integration closes it: it reads the hire event, applies your mapping, and creates the new hire or onboardee cleanly. In the other direction it keeps SmartRecruiters stocked with approved requisitions and positions so recruiters open jobs against real SuccessFactors data instead of free text.

What data moves

SmartRecruiters object / event	Becomes in SAP SuccessFactors	Notes
Candidate reaches Hired status	New hire in Employee Central, or onboardee in Onboarding 2.0	The trigger for the whole flow; keyed by candidate + application
Candidate personal data (name, DOB, email, phone, address)	PerPerson, PerPersonal, PerEmail, PerPhone, PerAddressDEFLT	Effective-dated as of the start date; country-specific address block for DE/AT/CH
Offer (start date, job title, compensation)	EmpEmployment, EmpJob, compensation payComponents	Start date is the valid-from for every effective-dated record; comp needs currency and frequency
Position / department on the application	Position externalCode, Job Classification, Legal Entity, Business Unit, Location	Must resolve to exact SuccessFactors foundation-object codes, not display labels
Resume, offer letter, signed documents	Employee documents / onboarding attachments	MIME and size limits apply; some route to onboarding rather than EC
Approved requisition / position (reverse)	SmartRecruiters job opening	Position, hiring manager, department and location pushed back into the ATS

The exact foundation-object codes, field mappings, and target process are agreed once with your HR-IT team and encoded in the pipeline. After that, nobody re-keys a hire by hand.

The details that break naive syncs

A point-to-point connector or a nightly CSV gets you the easy 80% and leaves the expensive 20% for HR to reconcile:

Foundation objects are codes, not labels. SmartRecruiters may carry a location as “Munich Office” while SuccessFactors expects a Location externalCode, a Legal Entity, and a Job Classification that resolve exactly. A near-match silently lands the employee in the wrong org unit. The mapping has to be explicit and validated against live SuccessFactors data.
Everything in Employee Central is effective-dated. A new hire is not a flat record - it is a set of composite entities (PerPerson, EmpEmployment, EmpJob) that all need a valid start date. Miss the effective date and the OData upsert fails or, worse, half-applies.
Rehires must not become duplicates. SuccessFactors keys people on person-id-external. A returning employee has to attach to the existing person, not create a second one. Naive exports insert blindly and pollute the system of record.
Offer changes arrive late. Start dates, titles, and locations move after the export. The hire has to be re-sent as a correction against the same key, not as a new employee.
Partial failures are real. An EC composite upsert can create the person but fail on employment or position. The pipeline has to detect the partial state, retry safely, and never double-apply the half that already succeeded.
Rate limits and delta windows. The SuccessFactors OData API throttles, and SmartRecruiters status webhooks can burst on a hiring day. A robust pipeline paces its calls, processes deltas rather than full reloads, and preserves ordering so an update never overtakes the insert it depends on.

How we build and run it

We treat this as a pipeline, not a nightly job somebody babysits. SmartRecruiters hire events are captured by webhook or polled on a schedule, validated, matched against existing SuccessFactors persons, transformed into your agreed EC or Onboarding payload, and written through the OData API - with the reverse requisition flow running the same way.

The pipeline is idempotent: every SmartRecruiters hire carries a stable key, so a retry, a re-run, or a late offer change never creates a duplicate employee. It runs on cloud-native, fully EU-hosted infrastructure, so candidate and employee data never leaves the EU, which keeps your DPA/AVV and GDPR obligations - and any works-council agreement - clean and auditable.

And then we keep it running. Monitoring, alerting, incident response, and watching for SmartRecruiters and SuccessFactors API changes are our responsibility under contract, with a named owner and an SLA. When SAP ships a new OData version or SmartRecruiters changes a webhook payload, that is our problem to fix before your next hire, not a surprise HR discovers on someone’s first day.

When this integration is worth building

If you hire a handful of people a month into a single legal entity, keying them into SuccessFactors by hand is genuinely fine and we will tell you so. The integration earns its place when hiring volume climbs, when you staff multiple legal entities and locations with strict foundation-object governance, when rehires and late offer changes make manual entry error-prone, or when a botched new-hire record means someone shows up on day one with no system access. At that point a managed pipeline is cheaper than the mistakes.