HR integration projects often start with the tool: “let us use OData” or “export a file from Integration Center.” Trouble begins when that choice is made before deciding whether the consumer needs one entity, the employee's hierarchical record or a scheduled extract.
OData, CompoundEmployee and Integration Center are not three equivalent products. OData and CompoundEmployee are interfaces with different contracts; Integration Center is a guided capability that uses the SuccessFactors data catalog to build and operate straightforward integrations.
1) Define the contract before choosing the API
Document five decisions first: the data the target needs, whether the flow reads or writes, acceptable latency, how changes will be recognized and who owns failures. Add effective-dated cases, retroactive corrections, rehires, global assignments and terminations; in Employee Central, the “current” record rarely tells the full story.
2) OData: entity-level precision and API operations
Employee Central OData APIs expose person and employment entities, foundation objects and MDF objects. They fit when the consumer knows the required entity, needs filters and field selection, follows controlled navigation properties or must create and update data where the entity supports it.
That flexibility requires design. Broad expansions can create expensive payloads; pagination, limits, permissions and effective-dated behavior must be tested per entity. A rule used by the user interface should not be assumed to execute the same way during an API call.
- Use it for: targeted queries, near-real-time integration, MDF objects, catalogs and authorized write-back.
- Avoid using it as: a shortcut to rebuild the whole employment record through dozens of calls without a consistency model.
3) CompoundEmployee: hierarchical employee replication
CompoundEmployee is a SOAP API designed to extract Employee Central master data. It returns the person as the root node and groups supported segments —employment, personal data, job information, compensation and more— in a hierarchical XML response.
Its strength is replication to SAP HCM, payroll, benefits or other consumers that need a composed employee view. It supports snapshot and delta transmission, and consumption is designed around query/queryMore, timestamps, action codes and time slices; it is not a general-purpose write API.
- Use it for: employee master data replication and consistent processing of effective or retroactive changes.
- Validate first: supported segments and fields, volume, delta window, pagination and how the target handles inserts, changes and deletions.
4) Integration Center: speed for simple scheduled scenarios
Integration Center lets teams build, run, schedule and monitor simple integrations through a guided workflow. It works well for configurable extracts to files or services, light transformations and CSV imports when the case does not justify developing and operating a middleware flow.
Speed does not remove boundaries. Multiple sources, orchestration, complex branching, durable state, high volume, versioned contracts or sophisticated recovery belong in a layer such as SAP Integration Suite. Teams should also verify the release documentation for the protocols, formats and OData generations currently supported by Integration Center.
5) Decision matrix
| Dominant need | Initial option | Why |
|---|---|---|
| Query or update a specific entity | OData | Entity contract, filters and API operations |
| Replicate hierarchical employee master data | CompoundEmployee | Related segments, time slices and transmission modes |
| Simple scheduled export to a file or endpoint | Integration Center | Guided configuration, scheduling and built-in monitoring |
| Multi-system orchestration and complex rules | Middleware + appropriate API | State, observability, retries and governance outside the extractor |
| Mixed HR scenario | Deliberate combination | Each interface keeps one bounded responsibility |
6) A delta is more than a date filter
A “last run” watermark is insufficient if the process ignores effective dates, future changes or retroactive corrections. The consumer should preserve evidence of the processed interval, use controlled overlap and remain idempotent so a window can be replayed without duplicate effects.
CompoundEmployee provides dedicated delta semantics, while OData strategy depends on the entity and its modification fields. The architecture also needs reconciliation: counts, unmatched cases and a way to rebuild state after a missed window. See the related guide to SuccessFactors deltas and idempotency.
7) Security and permissions change the result
The same query can return different data depending on the technical user's permissions. Use integration accounts, least-privilege Role-Based Permissions, credential rotation and environment separation; avoid personal credentials and payloads broader than the business contract requires.
A missing field does not always mean missing data: the chosen interface may not support it, the query may not select it or permissions may hide it. Diagnosis should distinguish those causes before anyone “corrects” the source record.
8) Design operations and tests before go-live
- Inventory entities, segments, sensitive fields and systems of record.
- Test hire, future change, retroactive correction, termination and rehire.
- Define pagination, checkpoints, retries and idempotency.
- Record correlation ID, processed window, result and rejection reason.
- Reconcile totals and exceptions with an owner and SLA.
- Document when to run a full reload and how to prevent double effects.
9) One architecture can use all three options
There is no benefit in forcing every integration through one interface. A company may use CompoundEmployee to replicate master data to payroll, OData to query specific objects from an application and Integration Center for a low-complexity scheduled export.
Mature design keeps contracts small and ownership visible. If the landscape combines SuccessFactors, HCM, payroll and external applications, a SuccessFactors integration architecture should state which mechanism owns each flow and how it recovers from failure.