This is part of an ongoing blog series on SAP SuccessFactors HCM implementation. In this post, we explore how to handle the rehire process, design options, dependencies, and recommendations. Implementing the right design eliminates manual work, enables reuse of existing employee identifiers, and efficiently supports other requirements. The content of this blog is based purely on my experience.
The rehire process in SAP SuccessFactors handles the return of former employees to the organization. Managing this effectively requires balancing data integrity (avoiding duplicate profiles) with process automation across Employee Central and Onboarding.
This blog is divided into two parts:
Part 1 – Covers the rehire options in EC and ONB, requirements validation, dependencies, and rehire check options for existing terminated, inactive employees in Employee Central (EC) and Onboarding.
Part 2 – Discusses design options and recommendations for detecting historical rehires who are not part of Employee Central.
1) Advantages of Detecting Rehire Records:
Identifying rehires before hiring has many advantages; the list is not limited to the following.
- Single Source of Truth (No Duplicate Profiles):
Prevents the creation of duplicate Person/User IDs and ensures all employment history (performance, training, personal data) remains linked to a single employee record.
- Accurate Benefits and Seniority:
Ensures correct calculation of tenure-based benefits, seniority, and vesting by retaining original hire date and service history.
- Compliance (GDPR):
Avoids fragmented personal data across multiple records, making data retention, audit, and “Right to be Forgotten” requests easier and more accurate.
- Rehire Eligibility Control:
Enforces rehire eligibility checks to prevent onboarding of employees marked as “Not Eligible for Rehire.”
- Downstream System Integrity:
Prevents duplicate identities across integrated systems (Payroll, Active Directory..etc), avoiding identity and provisioning conflicts.
2) Rehire Options for terminated employees who have data in SAP SuccessFactors HCM Employee Central:
When a terminated record exists in the Employee Central (EC) database, there are two options to rehire an employee in EC/Onboarding (ONB): Rehire with New Employment and Rehire on Old Employment.
2.1 Rehire with New Employment
HR BPs can rehire a former employee by initiating a new employment record. In this flow, a new employment portlet is added to the Employee Record. The Employee Central personal entities—such as National ID, Person ID, and Employee ID—continue from the previous employment. However, new entities for Employment, Job Information, Compensation, and other employment portlets will be added. Additionally, a new Assignment ID and User ID will be generated for the new employment record, differentiating it from previous employment. The employee profile of the rehired worker will include separate, distinct records for both the new and previous employment with the company.
2.2 Rehire with Old Employment
HR BPs can rehire a former employee based on one of their old employment records with the company. Every old employment is available as a profile to choose during the rehire process.
2.3 Comparison of both options and limitations
Rehire with Old Employment | Rehire with New Employment |
Updates the existing employment record with new job information. | Adds a brand-new employment entity linked to the same master Person ID. |
Keeps the original Assignment id/ User ID . | Generates a new Assignment ID / User ID. |
Seasonal or short-term returns where continuous organizational history matters. | Long-term rehires returning to a completely different legal entity, country, or department. |
Clean, unified career history layout; preserve historical learning and performance data directly on the profile. | Perfect separation of data for legal, taxation, and clear tenure/benefit resetting. |
Future-dated terminations aren’t currently supported when rehiring old employment. Future-dated terminations are situations in which the last working day is scheduled for a future date.
| Active employees with future-dated termination can be rehired on new employment |
Contingent to Regular, Regular to Contingent Rehires not supported | Contingent to Regular, Regular to Contingent Rehires supported |
3) Requirements Validation for Choosing New Employment vs. Old Employment
Validating customer-specific rehire requirements is a critical step in the process. These requirements vary from customer to customer; however, based on experience, the following are the most common use cases that play a key role in rehire process design and decision-making. The first four requirements focus on defining how the rehire process should function when a termination record already exists in the SAP SuccessFactors system.
Validating the business’s expected outcome for the rehire in each scenario and then making a final decision.
- Regular Terminated Employee: A regular employee who was terminated and is rejoining the organization as a regular employee.
- Contingent Employee: A contingent worker who was terminated and is rejoining the organization as a contingent worker.
- Regular to Contingent: A regular employee who was terminated and is now rejoining the organization as a contingent worker.
- Contingent to Regular: A contingent worker who was terminated and is now rejoining the organization as a regular employee.
- Talent-Only Record: Defines rehire behavior when only a talent profile exists in the system, without an Employee Central record.
- Integration Requirements and Dependencies: Identifying upstream and downstream system impacts, and the complexity of integration logic.
- S/4HANA and EC Payroll: Defining the expected behavior of EC Payroll during PTP replication and S/4HANA BIB replication.
- Data Migration Approach: Determining how historical data should be migrated and aligned with rehire scenarios, including any associated challenges.
- Identity Management Integration: Ensuring proper handling of user ID reuse, including the reactivation of old Active Directory (AD) profiles during rehire.
- Country-Specific and Payroll Requirements: Addressing localization needs, compliance requirements, and payroll system dependencies across different regions.
4) Recruit-to-Hire Process – Rehire Check Options in SAP SuccessFactors HCM:
As part of the hiring process, rehire detection is triggered across Recruiting, Onboarding, and Employee Central. SuccessFactors (SF ONB and EC) leverage standard capabilities to validate candidate attributes against the Employee Central database to identify returning employees.
4.1 Rehire Checks in SAP SuccessFactors RCM:
SAP SuccessFactors RCM does not provide native functionality to compare Job Applicant data against inactive Employee Central profiles to identify potential rehires.
Even if a custom integration is built to validate against EC data, reliable matching is still challenging because key identifiers such as National ID are often not captured in Recruiting, and in some cases, even date of birth is not available.
As a result, implementing an efficient and fully accurate rehire detection process in RCM is difficult. However, a practical approach is to explicitly ask candidates whether they have previously worked for the organization. If yes, additional details such as Employee ID and other known attributes can be collected and used to validate the record and flag potential rehires.
4.2 Rehire checks in SAP SuccessFactors HCM Onboarding:
Onboarding offers by default two rehire checks in the process, before creating any person in Onboarding, the first rehire check, also known as pre-onboarding rehire verification, is triggered.
Reference: The above diagram is from the SAP to help documentation.
When data is passed from Recruiting (RCM) or an external ATS into Onboarding , the system uses the following primary identifiers to run its matching algorithms:
- National ID / Government ID
- Personal Email Address
If the new hire isn’t identified as a rehire in the first rehire check, the second rehire check is triggered after the Personal Data Collection step. If the new hire is identified as a rehire after the second rehire check, one of the following apply for rehire with new and old employments:
- Rehire with new employment: The onboarding process as rehire is cancelled and restarted with new employment under the old Person Details.
- Rehire with old employment: After a rehire coordinator chooses one of the previous employment profiles during the rehire process, the previous employment under the same Person Details is reactivated.
4.3 Rehiring in SAP SuccessFactors Employee Central:
Pre-hire records coming from SAP SuccessFactors Onboarding to SAP SuccessFactors Employee Central trigger a rehire check within Onboarding. When a hire is made directly in Employee Central, the system performs a rehire check against the Employee Central database. If a potential match is found, the system provides an option to proceed with a rehire to a new employment or to the old employment.
If no match is found, the system treats the candidate as a new hire. The next blog will cover this topic in detail.
5. Commonly asked questions:
5. 1)How do date fields in Employment Information behave for different rehire options?
The behavior of the date fields in Employment Information varies depending on whether you rehire old employment or new employment. The following table describes how each date field behaves in these scenarios:
Technical Field | Rehire on Old Employment | Rehire on New Employment |
start-date | start-date | start-date |
originalStartDate | originalStartDate | start-date |
serviceDate | start-date | start-date |
seniorityDate | start-date | start-date |
benefits-eligibility-start-date | start-date | start-date |
5. 2) What is the recommended approach for Rehire?
It all depends on customer requirements. If there is no impact on payroll, integrations, or other differentiating factors discussed above, then hiring a new employee is cleaner. However, this decision should be carefully evaluated before being finalized.
5.3 )Have you seen customers using both the “Rehire with Old Employment” and “New Employment” options?
Yes, many customers adopt a hybrid approach based on use cases. For example, in scenarios such as Contingent-to-Regular or Regular-to-Contingent, they often use Rehire with New Employment. In other scenarios, they may use Rehire with Old Employment.
5.4)Is the rehire check triggered for records that exist only at the Employee Profile (platform) level?
It won’t trigger a rehire check. At the same time, when you hire an employee with the same IDs, the system will throw an error stating that a record already exists. Because there is already a platform record with the same user ID.
