Talent is where the suite decision gets reopened
Core HR lands in one system and stays there. Talent does not. Two years after a SuccessFactors go live, somebody in HR will put a specialist recruiting or learning product on the table, the systems team will push back, and the argument will run for a quarter. Recruiting, learning and performance are where this happens, because they are where the suite most often feels thin and where the specialist market is deepest.
The argument gets framed badly on both sides. HR argues capability, because they sit in the product daily and can name ten things it does not do well. The systems function argues coherence, because they carry the integration estate and know what a fourth interface costs. Neither side is wrong, and nobody has written down which question the business is actually asking.
The question is narrower than build or buy. It is whether a talent process is better served by a delivered module that already reads the record of truth, or by an outside product that has to be told about the organisation.
The suite argument is about the worker record
The strongest case for keeping talent inside SuccessFactors has little to do with features, and people who argue it on features lose. Talent processes are worthless if they run on stale organisational data. A performance cycle that routes to a manager who moved in March produces a review nobody signs and a compensation round that pays the wrong hierarchy.
Inside the suite that problem does not exist. A performance form and the organisation structure read the same objects, so when a reporting line changes, every talent process sees it the moment it takes effect. Nothing has to synchronise, so nothing falls behind. That is the whole of the suite argument and it is a strong one.
The largest failure in a specialist deployment is exactly this drift. The specialist view of who reports to whom, which position is open and which employee sits on what contract stops matching the record of truth, and it stops matching quietly. Nobody notices until a requisition gets approved against a position closed in the last restructure. The same failure shows up between HR and finance, which is why worker master data across SuccessFactors and S/4HANA belongs in the same conversation.
How much you reorganise decides what you can tolerate
The real question underneath the talent decision is how much organisational change the business has. A stable organisation tolerates a loosely synchronised specialist far better than one that restructures every year. If your position structure in December matches the one you had in January, a nightly feed with a day of latency costs you very little.
An organisation that reorganises constantly is a different case. Every restructure means new positions, retired positions, moved reporting lines and employees whose contracts change shape. Each has to land in the specialist before it makes a decision that depends on it, and the window where the two disagree is the window where wrong things happen. Our guide to integration that survives a reorg exists because that is where most SuccessFactors interfaces break.
Ask the HR operations lead how many organisational changes they processed last year and how many were backdated. The second number matters more, because backdated changes mean the feed has to carry effective dating correctly, and effective dating is where most talent integrations quietly fail.
Recruiting faces outward and learning follows the content
Recruiting is the clearest case for a specialist, and the reason is structural. It faces outward to candidates rather than inward to employees, so a slow or awkward application experience costs you applications and you never meet the people who abandoned it halfway. Every other talent module serves a captive audience who will use whatever you give them.
Recruiting also sits against an outside market of job boards, assessment providers, background check vendors, agencies and scheduling tools. A specialist usually maintains those connections itself and sells them as part of the product. A suite module may cover some and need middleware for others, and the honest answer depends on your modules and your agreement, so make the vendor write that list down.
Learning is the second clearest case, for a different reason. The value sits in content and delivery rather than record keeping. The catalogue, the authoring tools and the content marketplace decide whether anyone finishes a course. The record of who completed what matters for compliance, and it can live outside the suite as long as it reaches the worker record reliably.
A blunter version of this rarely gets said out loud. A suite module the HR team resents will underperform a specialist they like, because adoption determines value in talent far more than in payroll, where correctness decides the outcome and nobody opts out.
The integration bill nobody prices properly
Teams price a specialist as one interface. It is never one interface. At minimum you own a worker feed, a position feed, an organisational hierarchy feed and a writeback that turns a hire into an employee record, each with its own timing and its own failure mode. The writeback is the one that hurts, because a failed hire writeback means somebody turns up on a Monday with no record.
Each feed needs a stable key, which teams discover late. If the specialist identifies workers by email address or by name, the rework arrives after go live rather than in design. That is ordinary durable business key work, and most of the difference between a connector and an integration.
Somebody owns all of that forever, not for the length of the project. If you cannot name the person whose phone rings at six in the morning when the position feed fails, you do not have an integration, you have an intention. The same error handling that pages someone applies here.
Candidate data carries an obligation employee data does not. Candidates you never hired have their own retention rules, consent given for one purpose, and a right to removal your employee policy does not cover. A specialist gives you a second store of personal data outside the boundary your HR systems team controls, and somebody answers for it at audit.
Configuring around the suite spends what you bought
The suite side has a cost teams underestimate too, and it arrives in a workshop decision that looks harmless. The delivered process does not match how the organisation runs performance today, so the build configures around it with extra rule sets, extra routing steps and extra fields that preserve a practice designed in the system you are replacing.
Every one of those spends the coherence you bought the suite for. You end up with a talent process that upgrades awkwardly and that nobody outside the two people who built it understands. The worker record is still shared, which was the point, but you paid in configuration debt instead of interfaces.
The test is whether the practice you are preserving earns that cost. Works council agreements do. A calibration model the executive committee genuinely runs on does. A rating grid that survives because a consultant drew it years ago does not, and keeping it costs more than most HR teams admit.
The question to force into the evaluation
The suite tends to win when organisational change is frequent, when the process faces inward to employees, and when nobody will own an integration after the project closes. Performance and succession usually sit here, because they read the hierarchy constantly and their value comes from the data being right rather than the experience being pleasant.
A specialist tends to win when the process faces outward, when the capability gap is real rather than cosmetic, and when the organisation has genuine integration capacity with a named owner. Recruiting usually sits here and learning often does. Make the sponsoring team state the gap in plain terms, because a team that cannot describe what the specialist does differently is describing a preference.
Put one question into the evaluation and make both sides answer it in writing. When a position is created, changed or closed in SuccessFactors, when does the specialist know, what happens to a requisition already open against it, and whose phone rings when the answer is wrong. If the vendor cannot answer that in a demo, get the answer before contract, and run that demo on your terms rather than theirs.
