The file that was right a week too early
A benefits extract at a manufacturer ran cleanly for two years, then sent four thousand employees into a new plan year priced on last year's salaries. The job had been built in Integration Center in an afternoon and scheduled for the Thursday before the first of April. It read compensation as of the day it ran.
The annual review took effect on 1 April. On 26 March those pay records already existed with a future effective date, and the extract skipped them, because nobody had set an as of date on the query. The provider priced cover on what it received. An employee questioned a deduction in June, three payroll cycles later.
Nothing in the product was broken. Integration Center exists so an HR systems team can ship a working extract without opening a middleware project, and that speed is the reason extracts end up carrying payroll and finance data with nobody reviewing the one setting that decides whether the file is right.
What the tool builds and the choice you cannot take back
Integration Center builds a small set of shapes. An outbound file written over secure file transfer in delimited, fixed width, XML or JSON form. An outbound call posting a similar payload to a REST endpoint. An inbound file that loads data back into SuccessFactors. Most teams only ever build the first one.
The first screen asks for the integration type, the format and the starting entity, and that combination is fixed for the life of the job. A job that starts from employment information cannot be switched to compensation information later, and a delimited job cannot become a JSON job. The only route is a new job with the fields, filters, destination and schedule rebuilt from nothing.
Pick the starting entity by asking which record the consumer counts. One row per employment relationship starts from employment information. One row per active assignment starts from job information. A dependant file starts from the person entity and reaches the rest through associations. Choose wrong and every later fix is a workaround, either duplicate rows the consumer has to collapse or a missing relationship that forces a second extract.
The date filter decides whether the file is correct
Effective dated entities hold one row per change with a start and an end date, and job information, compensation, personal data and organisational assignment all behave this way. A query with no date instruction returns the row current on the day it runs. That suits a headcount report and suits almost no downstream consumer.
Payroll wants the record in effect on the period end date. Finance wants the last day of the accounting period. A benefits provider wants the plan year start. Integration Center offers an as of date, a date range and offsets from the run date, so a job can ask for the record in effect on the first of next month.
A wrong date filter still produces a file. Row counts match, every column is populated, and the values belong to the wrong day. Agree the as of date with the consumer in writing, then prove it against one employee with a known future dated transfer and check which cost centre the file carries. Get this wrong and the worker data finance receives is quietly wrong with it.
Fields are cheap and traversals are not
Field selection is the straightforward part. Pick fields from the starting entity, rename the labels the consumer sees, translate codes through a lookup, and set defaults for empty values. Do the renaming here rather than asking the consumer to map your internal labels, which they will do once and then forget.
Associations are the part people underestimate. From the starting entity you can traverse to related entities, so a job information extract reaches the position, the department, the manager and the manager's manager. Each hop is a join at run time. Two hops over ten thousand employees is fine. Four hops with a filter on the far entity turns a three minute run into forty minutes, and a long run eventually collides with the next one or with the maintenance window.
Two failures deserve naming. A traversal into a one to many association multiplies rows, so a file meant to carry one line per employee arrives with one line per pay component. And a field the technical user cannot read comes back empty instead of raising an error, so an unrelated permissions change empties a column nobody re-reads. Keep traversals shallow and the field list short enough to sit inside an integration contract someone can read in one sitting.
Destinations and the schedule nobody re-checks
The destination lives inside the job. Host, path, credentials and optional encryption for secure file transfer, or an endpoint with its own authentication for an API call. Every job carries its own copy, so the day a provider rotates a key, somebody edits each job that points at it. Count them before the change rather than finding them from failure emails.
Schedules run in the server time zone, not yours. A file that must land before a payroll cut off at seven local time needs the offset worked out once and written next to the schedule, or whoever inherits the job will not know why it fires at an odd hour. Daylight saving moves the local time twice a year while the server stays put.
After an instance refresh the copied jobs still point at production destinations. A casual test run in the refreshed sandbox delivers a full production file to a live provider, and the provider loads it. Disable schedules as part of the refresh runbook and check the destination host on every job before anyone runs one by hand.
What happens when the run fails at three in the morning
By default, nothing happens. The run lands in the execution history with a failed status, no file is written, and nobody is told. The consumer's overnight import finds no file and does nothing about it, because an import with nothing to read logs a line and exits clean. Payroll asks about three missing starters a week later.
Notification settings sit on the job's schedule and take addresses for success, failure or both. Send failures to a shared mailbox a named team reads each morning rather than to one person, since that address leaves when the person does. Switch success notices off once the job is stable, or people stop reading either kind. Then ask the consumer to alarm on a missing file, because error handling that pages someone is the part Integration Center cannot do for you.
Before payroll, finance or a provider is allowed to depend on a new extract, I walk the same short list with whoever owns the consuming system.
- The as of date agreed in writing, and proved against one employee with a future dated change.
- A full run reconciled to a count the consumer already trusts, with any difference explained.
- One deliberate failure, to confirm the alert reaches a mailbox somebody reads each morning.
- An alert on the consuming side when no file arrives by the agreed time.
- The technical user's permissions recorded, so a later security change cannot silently blank a column.
- A named owner for the job, the destination host and the credentials, with the renewal date written down.
Where the tool stops being the right answer
Integration Center suits a scheduled extract with simple shaping and one destination. Plenty of teams run files that matter this way for years without trouble, and moving them to middleware would buy a longer change process and little else. A nightly file that lands in one place and has not changed shape in eighteen months belongs where it is.
Four signals say a job has outgrown it. You need per record error handling, so one bad row is quarantined while the rest deliver. You need retries, because the destination goes down occasionally and a failed run currently means a lost day. You need transformation carrying business rules, the sort that reads another system or applies logic finance owns. Or three consumers want the same data in three formats, which here means three jobs drifting apart at three speeds.
Then the answer is a real integration platform, with the middle layer owning retries, routing and monitoring while SuccessFactors answers queries. That move costs money and time, so argue it from a failure you can already name rather than from tidiness, and take the same care over ownership that keeps an extract alive through a reorg.
Open the execution history for your three busiest jobs this week and check two things on each. Who receives the failure email, and which date the query reads. If either answer takes more than a minute to find, you have found this quarter's work.
