- Rehire with old employment functionality is added as part of B2205 release. Here are few FAQs on the topic
SAP SuccessFactors Onboarding
Q1: Since ROOE is not GA,if we provide ROOE switch in onboarding general settings, how we can prevent client enabling this switch
A1: This ROOE feature will be behind a feature toggle. so, we only turn this ON for customers who have signed up for early adaption program. We need to enable the feature toggle to view this setting, the switch to enable ROOE will not be shown to all
Q2: Are Oninit and onchange rules supported in RHDR page?
A2: OnInit is not supported. OnChange is supported
Q3: If we have existing values in DB record and new values are passed from RCM, which is given precedence?
A3: RCM data (assuming the MATCHCONFIG data is set to copy DB data)
Q4: Can the RHDR step assigned to a responsible group?
A4: RHDR page is assigned to Rehire Coordinators. Unlike Rehire on New Employment, the rehire coordinator who accepts match on the Rehire Verification Page is immediately redirected to the RHDR page, hence the same user is responsible for both the steps.
Q5: Can we have rehire coordinators seeing and accessing only rehire verification tasks that belong to their Legal Entity?
A5: we can define multiple groups and can be selected via Business rule. For example, we can have rehire coordinators for Germany, US, India etc and based on the rehire location, Business rule can select the relevant Group that needs to act on this rehire match
Q6: Sync between RHDR (merge) to employee profile happens based on HRIS sync job in provisioning or does the sync happen via code? What is frequency of sync?
A6: It happens via the code once post RHDR after the internal user conversion, post this, the frequency is as that of the new hire in further steps.
Q7: If you are using the "manual" onboarding start feature, will that trigger the rehire check as well?
A7: MVP handles RCM based initiation. Manual Onboarding falls under ATS and not covered as part of b2205. will be taken care in B2211
Q8: It would be great if we have restart email trigger to rehire co-ordinator to complete step post second re-hire check
A8: Part of Enhancement
Q9: Will the tasks assigned to the new users account be moved to the old account?
A9: There will not be any tasks available for the old login ID, post RHDR restart all activities and tasks will be realigned to the rehired user. Also, with this we still are consuming 1 id and cannot free it
Q: If I do not have NHDR in the Process variant, will the RHDR step be triggered?
A: RHDR is triggered only if you select the match as "Rehire on Old employment" in the Rehire verification page. You CANNOT have this page on demand.
RHDR is super powered page it merges the data and also ensures that employee data model is enforced
Q: On cancelling ROOE, if data is merged with old record how to identify and purge it? pls advise on best practice
A: It will be manual process and the guide will be updated with the relevant Information. For this release at-least there won't be any data purge / revert of merged data by system.
Q: Do those overwrites show up in audit trail somewhere else? for the non-effective dated entities?
A: change audit log includes non-effective dated entities
we reactivate the terminated user and convert them to active external user (f -> e) and the username of the terminated user is used (user name reuse is same as that of rehire on New Employment).
- Rehire Data review page (RHDR) page honours Employee data model.
- Rehire Coordinator performs the relevant changes.
- Merge of DB and RCM/ONB is performed - preference is for data coming from RCM/ONB. RCM data if first rehire check is successful and (RCM +ONB ) Data for second rehire check.
- Every entity merge behaviour is captured in confluence and differs on field level merge or entity level merge.
Important differences in behaviour with respect to existing Rehire on New Employment :
Rehire on New Employment
Rehire on Old Employment
NHDR respects Onboardee Data Model
RHDR respects Employee Data Model
Rehire Verification and NHDR are separate tasks and could be performed by different users
Rehire Verification and RHDR are consecutive steps tied to the same todo task and must be completed by the same user
Data Merge happens in the backend first and is then reviewed by the relevant user on NHDR
Data Merge happens only on the UI for a review and data is not saved to the system unless reviewed and adjusted by the rehire coordinator user
Only Person Data is merged
Both Person Data and Employment/User Data is merged
Post second rehire check, NHDR and PDC need to be completed again
Post second rehire check, NHDR and PDC need not be completed again, and would be skipped automatically
Additionally, NHDR is always accessible from the dashboard even after RHDR for a Rehire on old Employment candidate for any further modifications
Since we are using Rehire On Old Employment - HiringNotComplete flag is retained as "False" and WILL not be changed to "true". Integrations using this flag may have a problem and that is the reason why OnboardingInfo Entity is used.
OnboardingInfo is now added as a child navigation of EmploymentInfo and will be present if and only if that particular employment is managed by Onboarding. OnboardingInfo is exposed in EC Compound API and can be leveraged for integrations. For those customers who do not have ROOE enabled, will not have any problems.
OnboardingInfo will be created for Onboarding, Crossboarding and even for Offboarding types
Onboarding Info will have a SubType that says what flavor of Onboarding the current new/Cross/Off boardee is undergoing.
Sub Type can be one of: Rehire on Old Employment/ Rehire on new Employment / New Hire
Rehire with old employment, Onboarding, Rehire, ROOE, B2205 release, release update , KBA , LOD-SF-OBX-RHM , Rehire Mechanism , Problem