← All posts
August 8, 2026·Recruiting operations·11 min read

SmartRecruiters is coming to SuccessFactors

What to know before you configure it, whether it is arriving in your SAP environment or you are moving to it from somewhere else

SmartRecruiters is now SAP's recruiting platform, and SuccessFactors Recruiting is not where the new development is going.

Some context that shapes how people are planning:

So this is not a data migration. It is a rebuild with a configuration head start.

The version sold and implemented through SAP is called SmartRecruiters for SAP SuccessFactors. From what SAP and SmartRecruiters have published, that is the SmartRecruiters platform with the native SuccessFactors integration on top, presented inside SuccessFactors itself, with one login and shared navigation. The connections are named User Sync, Configuration Sync, Job Sync, and Hire Sync.

If you are on SuccessFactors, you are not switching systems. SuccessFactors stays and recruiting moves into SmartRecruiters. If you are coming from a different ATS, or from no ATS, you are doing a real migration.

For the SuccessFactors path specifically, SmartRecruiters has a tool called Migration Hub that reads your SuccessFactors recruiting configuration and helps you rebuild it on the SmartRecruiters side. It handles the mapping. It does not make the decisions, and the decisions are where the time goes. Links at the bottom if you want the detail.

Either way, what follows is about how the platform behaves once you are configuring it, which is the same work in both cases.

This is not a review of SmartRecruiters. It is the list of things that gave me grief, or that I wish someone had told me before I started configuring rather than after. The things I like could be a different post in the future.

Hiring processes and approvals are separate things

This is the piece of SmartRecruiters architecture worth understanding before you design anything.

The hiring process is the stage flow. It is what a candidate moves through and what your team works from day to day. Job and offer approval chains are configured separately, and they can be scoped by org field values. That means one hiring process can serve several business units while each one routes through its own approval chain.

The practical effect is that you do not need a separate hiring process every time a business unit needs different approvals. You can build two or three hiring processes that reflect how you actually recruit, and let the approval routing handle who signs off on what.

The trade is that the org field structure you set up early can determine what approval routing you can build later. Give it the extra hour.

Verify the specifics against your own licensing tier before you design around it. Feature availability varies, and your account team will answer that faster than documentation will.

This is a strong system if you run multiple brands

If you are a single company with a single career site, plenty of platforms will do. If you are carrying several brands, especially through acquisition, SmartRecruiters handles it well.

SmartRecruiters has a brand field out of the box, and for a lot of organizations that is enough. You can externally show one or multiple brands.

If you are a multi-entity organization with one public brand, my suggestion would be to set up your one brand under Brands, then add an org field for the other entities. That org field drives routing, and gives you something to map against if you integrate with your payroll system. I rebuilt a client's that way, and it is the change that made the multi-brand structure actually work and become customizable to the differing needs and processes of each entity.

Once brand is doing that job, onboarding an acquired business becomes adding values and mapping them rather than rebuilding configuration, which matters a lot if you are acquiring regularly. It is the reason I would put SmartRecruiters on the list for a multi-brand organization before I would put it on the list for a simpler one.

Job templates do not work the way most ATS platforms do

Most systems give you a template administration area where you open a master template and edit it directly. SmartRecruiters does not work that way. Once a template exists, much of the ongoing maintenance happens while you are working from that template during job creation, and saving those changes back.

It is not difficult once you have seen it. It is different enough that administrators go looking in Settings for a screen that is not there, decide the feature is missing, and create a second template instead of updating the first.

Before you train recruiters, write down how your organization creates, updates, and retires job templates, and give one person ownership of that list.

What you cannot delete

Tags. A tag cannot be deleted while it is applied to a candidate. There is no tag library sitting behind it either, so once nothing carries a tag, it stops existing on its own. The catch is that the only route from "runner up" to "runner-up" runs through every candidate already carrying the wrong one. Apply the right tag, remove the wrong one, repeat until the count reaches zero. Early on that is a handful of records.

Job and org fields. Once created, these cannot be deleted at all. You can deactivate them or repurpose them, which handles it operationally, but they stay in the instance. That matters more than it sounds, because there are caps: SAP documents a limit of 200 job fields including inactive ones, and a maximum of 22 custom org fields. Deactivated fields still count against the ceiling, so a messy first pass costs you room later.

Automated communication templates. These are not easily removed either, and it is not something an admin can do from the interface. Be deliberate about which ones you create and turn on, rather than building a few extras to see how they look.

None of this is a crisis. All of it is cheaper to get right the first time than to tidy up later, and getting it right costs about an hour of writing down a naming convention before anyone creates the first one.

There is also no bulk edit in the interface for adding an org field or job field to jobs that already exist. The API can do it if you have someone who can script against it, but through the interface it is one job at a time. If you decide in month three that every requisition needs a new field populated and you have several hundred open, plan accordingly. Better to settle the field structure before you have volume.

Archiving an org field value does not retroactively clean jobs that already carry it. Archiving governs future selection, not past assignment, so you can archive a brand and still find it sitting on live requisitions. Sorting that out is usually a business decision about where those jobs belong now rather than an admin task.

Communities and segments

Communities are SmartRecruiters' talent pool structure. They are groups of candidates and prospects you keep warm outside of any single job, so you can build a pipeline for roles you hire repeatedly rather than starting from zero every time a requisition opens.

Segments live inside communities, which is why the structure matters more than it first appears. A community that has been collecting candidates for six months, with segments built underneath it, is not something you casually restructure. Decide the shape before recruiters start adding people.

Users, roles, and access groups

Three separate areas in Settings govern who can see what: System roles, Access groups, and Hiring team roles.

They interact, and they present a lot of detail. It is very possible to configure one of them correctly and still hand someone access you did not intend because of what the other two are doing. Look at all three before you finalize anything, and test by logging in as a real account rather than reading your own configuration back to yourself — especially the hiring manager access to all jobs versus just the jobs they are assigned to.

Bulk uploading users

Bulk upload creates users, not candidates. If you are on the SuccessFactors path, User Sync handles this: it creates, updates, activates, and deactivates SmartRecruiters users from Employee Central. The CSV route below is mostly for everyone else, or for users who sit outside that sync.

Bulk upload sits under User Management. You assign the groups, download the CSV, fill it, and load it back. The file is particular about what it wants.

Required columns are first name, last name, email, and system role, plus SSO identifier if SSO is enabled. Access group is optional, with one trap: Employee is a system role, not an access group, so putting Employee in the access group column will error the row.

Whether accounts activate on upload is driven by the activation column, set to TRUE. When they activate, each user gets a notification prompting them to sign in. That is worth planning around. Having your documentation and a short "here is what this is and what to do" message ready before you run the upload is the difference between a smooth rollout and a few hundred people getting an unexplained email from a system they have never heard of.

Integrations and credentials

If you are connecting an outside tool, a programmatic job advertising platform for example, that connection is built as a custom integration under Apps and Integrations rather than picked off a vendor list. SmartRecruiters has offered SmartJobs, but check with your account rep, as availability differs. If you want programmatic and SmartJobs is not available to you, other programmatic solutions like JobTarget are straightforward to implement.

To do that, you will likely want to create a dedicated system role and access group for it instead of attaching it to an already configured role, where the permissions could be broader than the integration needs. Choose the endpoints you expose deliberately, which the platform does let you control.

Then make one test call with that credential before you hand it to anyone, from the command line or a tool like Postman, and look at what comes back. A credential you think is scoped correctly can end up with more access than you intended, or less than the integration needs. It is a great way to know for certain what that credential can reach.

Winston Match

Winston is the AI running across the platform, and Winston Match is the piece most people meet first. It scores incoming applicants against the job on a star scale, tells you why it landed where it did, and breaks the score down into skills, experience, and education. Those three can show as a column in the applicant list, so during high-volume screening you can see what is driving a score without opening each profile.

The practical part is that access is easy to turn on and off per user. You do not have to make an all-or-nothing decision for the whole organization. Start with a team, see how the scores line up against what your recruiters would have picked themselves, and expand from there. You can flag scores or reasoning that are incorrect or not reading the resume accurately.

Sandbox

A sandbox is not automatically included. If it is not in your contract, testing happens in production with carefully managed test data. Confirm it at contract time rather than discovering it mid-build.

The good news

A system migration is a bit like clearing out a closet. Some things still fit and come straight over. Some things you have been carrying for years and will not miss for a second. And a few things now exist that you did not have before and would not have gone looking for.

It is genuinely one of the better moments to look at how your systems connect, who needs access to what, and what you are still doing by hand. For a short window everything is on the table and nobody can tell you it is just how the system works.

For what it is worth, I like working in SmartRecruiters. I find it intuitive, and I think you might too.

Everything here comes from working in live SmartRecruiters instances and from SAP and SmartRecruiters published material. It reflects my own observations and opinions, not the position of SAP, SmartRecruiters, or SuccessFactors, and none of it should be read as a product roadmap or a commitment from any of them. Platform behavior varies by licensing tier and configuration and changes between releases, so verify anything here against your own instance before you build on it.

Kate Rose is a fractional Head of Talent based in Raleigh, NC. She builds and rebuilds talent acquisition systems for companies scaling through acquisition, including a multi-entity SmartRecruiters rebuild that reorganized brands, org fields, and approval routing around how each business unit actually hires.

Sources tap to expand

A platform change is the one window where the field structure, approval routing, and access model are all still on the table. That is what the Talent Systems Manager engagement is built for.

See Talent Systems Manager → Review a hiring decision →