Master Data Purge – Preparing an existing Successfactors EC Instance for new data conversions

[KavitaJain11]

Converting HR master data successfully is key to the success of a project. There are times when we have lot of transformation of data due to a change in the enterprise structure or other areas. Based on project scope there are situations where multiple cycles of conversion are necessary for success.

For every conversion cycle and iteration testing there could be a need to clean up the foundation as well as employee data for the below reasons

• Change in foundation object such as adding more locations, departments etc.


• Change in the way that the Org structure is designed


• A fresh set of employee data is needed for payroll comparison testing.


• Refreshing the EC instance through a copy from another EC instance is not an option

In the SAP ECC world a new “clean” client can be made available through a system or client copy, but in the EC environment, more steps and coordination are needed.

There are number of products available in the market place for SAP ECC master data replication or refreshes from and existing ECC system. One of the best tools in industry is ‘Data Sync Manager’ from EPI-USE Labs.

There are a few options to prepare a new EC Instance for Data Conversion test cycles.

• Option 1 is to start with a fresh instance (no configuration or data). The standard Configuration Sync tool has been a good help in moving configuration to the fresh instance, but even then, there is still a lot of challenges in bringing a to a fully configured status, since there are many manual tasks required as well. All these activities take a lot of time to create and prepare a new instance for employee data conversions.


• Option 2 would be to log a support request to Successfactors to copy an existing configured EC instance with data to a new instance, and then purge the data. The new conversions can then be done after the existing data has been purged.

Purging data that include concurrent employment, however, presents additional challenges to be considered, which we want to share with this blog.

In summary, purging data can comparatively be a faster way to prepare an instance for your next conversion cycle. Below is the high-level process for purging data and reloading of master data.

High Level Process for Purge and Reload

The process below outlines the steps to be followed when cleaning up the data in the instance between testing/conversion iterations. This process includes in sequence a full purge of employee data, and then a partial purge of Foundation data.

Transaction codes

1. Data Retention Management >> Soft Purge and Permanent Purge


2. Maintenance Monitor >> Approve request for Purge


3. Monitor Job >> Error logs


4. Import and Export Data >> Deleting MDF data

Employee Data Purge

1. Always Purge Employee Master data before purging any foundation data. To begin the employee data purge, perform a User Export to review all the user ids active and inactive in the system.


2. Identify the users and divide the list in below groups
   
   
   
   • A: Admin, Integration, Security users etc... These users should not be purged, they should be added to do not Purge list.
   
   
   • B: Inactive Users – These are ready for Purge users, they are already terminated in employee central or inactivated in employee profile.
   
   
   • C: Active users with no data in employee central – Need a basic user file import, to inactivate them, after which they can be purged
   
   
   • 😧 Active users with data in employee central – Need to be part of mass termination, after which they can be purged
   
   
   
   


3. After the users are identified, use the tools provided in the system to clear out any active forms for these employees in Compensation, PMGM and other modules in scope.

Below Options are available in Data Retention Management:

• 
  
  
  
  • Purge PM or SM data
  
  
  • Purge Learning Activity
  
  
  • Purge Development Objective
  
  
  • Purge Career Worksheet
  
  
  • Purge Calibration
  
  
  • Purge Objective
  
  
  • Purge Inactive Job application
  
  
  • Purge Inactive Candidate
  
  
  • Purge Compensation/ Variable Pay data
  
  
  • Purge Time Management Data
  
  
  
  

4. Upload a basic user info file to inactivate the basic user records from group C.


5. Terminate all employees from group D using mass termination with an effective date of today minus 1, since terminations are effective the next day.


6. Initiate an inactive user purge (soft purge) from the Data Management tools for the full user list of group B, C and D.

Example - Email generated for Soft Purge

7. Once its approved you can see the log in approved request, and also download the user file  that was approved.

8. Review the purge job results and resolve any issues and rerun if necessary. Once all the purges have completed, continue to the next step.


9. Initiate a permanent purge from the Data Management tools for the list of users that were purged.

Example - Email generated for Permanent Purge

10. Review the purge job results and resolve any issues and rerun if necessary. Once all the purges have completed we can move on to the foundation data purge.

Purging employees with Concurrent Employment

1. Compile a report of employees(user) with all their assignments in the EC instance


2. Term all these assignments using mass termination in Employee central (Mass upload Job info and Employment Info)


3. Using the Data retention tool, Soft purge all these employees using the file upload feature. When files are split (to manage size and volume) make sure the all assignments of an employee remain in the same file.


4. Permanent purge all employees, and remember when the files are split, all assignments of an employee should remain in the same file.

Foundation Data Purge

1. Delete any position requisitions – this can be done in the Recruitment Module.


2. Using reports, Import and Export Data or other built-in extraction tools, extract current foundation object tables (Department, Location, Job Codes, Positions, etc.…) that are relevant to the testing/conversion.


3. Either delete all foundation data and reload the new files, or compare current values with updated Foundation Objects, and import only new values and changes, while deleting the obsolete values.


4. Validate the foundation data


5. The system is now ready to convert/reload new employee data. At this point any previously used user IDs can be reused or employees can be loaded with different IDs.

Key Considerations while Purging the data

The master data purge process is designed to ensure that data across the HCM Suite
is purged first, before the user account, to avoid orphaned data. Below are tips and tricks which are key to successful data purge

1. First Identify the data that might get orphaned due to purge and delete them. Some of the examples below:
   
   
   
   • To do task - The best way to clean up the to do task is to clean up all the pending workflows. If you are purging whole population this will be taken care by Purge process, however if you are purging partial data then this is a manual task before master data purge.
   
   
   • Pending workflows – Go to Manage workflow request and find all pending workflows, change the routing to yourself and complete them. It applies for partial data purge.
   
   
   • Pending Documents should be purged in their respective modules
     
     
     
     • Position Requisitions
     
     
     • PM GM forms
     
     
     • Comp Forms
     
     
     • Other modules
     
     
     
     
   
   
   
   

2. Double check all the MDF object data tables after permanent purge to make sure it is deleted using import and export data transaction, some examples..
   
   
   
   • Payment Info
   
   
   • Alternative Cost Distributions
   
   
   • Spot Bonus
   
   
   • Recurring Deduction
   
   
   • One Time Deduction
   
   
   • Time Off
   
   
   
   

3. Manage pending Hire and Internal Hire Queue - In order to clear them, delete MDF object “Onboarding Candidate Info” using import and export data transaction


4. Offboarding Data - To clear Offboarding data, delete MDF object “OffboardingUserInfo” Using import and export data transaction


5. RBP assignment check – When data is purged, an email is triggered to all participants who has the below permissions. In order to avoid unwanted email notifications to all users, these permissions can be assigned in a separate role and the role assigned to selected individuals who should be notified.

Refer to KBA #2088065 listed at the end of the document for more detailed information on permissions.

6. If you have Concurrent Employment Active, then you have to purge all CE assignment in the same file


7. If your number range have leading zeros, then make sure when preparing your CSV file, the leading zeros are not removed.


8. User performing purge has admin rights on the LMS (Learning) module, otherwise he won’t be able to Approve the Purge Requests. Refer to below KBA’s for more information


9. The User ID (personnel number) cannot be reused for conversion unless they are permanently purged.


10. Size of the purge file should be not more than 500 to 1000 pernr for soft purge and 2000 to 3000 for permanent purge to get the best results. If the files are too large specific error text may not be provided by the system.


11. During the reconversion process, you may still get an error message that an employee is purged and cannot be reactivated. In Such scenarios you can upload a basic user info file for these users and then overwrite them with the conversion tool


12. Always convert main assignment pernr before converting secondary assignments for CE scenarios.

Reactivating a Purged User - Automated

Once all data is purged, we can reconvert all employees using SAP Cloud Platform and Integration Services as the middleware software. This is an automated / web services approach.

While using this tool the common issue is error “USER IS PURGED”

This seems to be a bug because, only few employees fail due to this issue. The workaround we found was uploading a basic user file and reactivating the pernr (This step is after permanent purge) Once reactivated, we were able to reconvert data for the employee.

Reactivating a Purged User – Manual Process

Data can also be reconverted using below steps manually

Without Concurrent Employment assignment –

1. Upload basic user file and reactivate the employee


2. Upload Employment Info, Job info, Comp Info as separate files using import employee data functionality.

With Concurrent Employment assignment -

1. Upload basic user data for main assignment, the username uploaded will be same as main assignment, but it should be changed to a different username since employee central stores different username per assignment.


2. Upload employment info using Import employee data


3. Upload Job info using Import employee data


4. Upload employment details for secondary assignment


5. Upload job info for second assignment


6. Upload all other sections for all assignments

References in SAP Knowledge Base

Detailed KBA on Purge process

• 2088065 - Data Retention Management - Purge Data - Platform


• 2103423 - DRM 2.0 to purge inactive candidates and / or inactive applications - Recruiting Management


• 2392076 - User Permanent Purge feature

Reactivating a Purged User

• 2392094 - Re-activate a purged user via employee import feature


• 2202987 - How to create Concurrent Employments via Import

KBA on error resolutions

• 2520038 - User Purge Error: 500 - Deletion of the user failed –                                              Cause and Resolution
  
  
  
  • The resolution for this situation currently, is to create the user in Learning with the same user information or disable the Learning integration in provisioning, otherwise the "500 - Deletion of the user failed" error will be shown and the user will not be purged from BizX.
  
  
  • IMPORTANT CONSIDERATION:                                                                                      After release b1708, LMS Users ID that were purged/deleted no longer can be used in the learning system. If you have an integration and are planning to re-use the same ID, we do not recommend the purge process.
  
  
  
  


• 2179378 - Unable to purge inactive user - status is failed.                                                Resolution
  
  
  
  • Please uncheck the box "There is data for this user in Employee Central (EC)", if not the user would be excluded from the purge.
  
  
  • If the Learning Managment System (LMS) is integrated and the purge failed please follow the next steps:
  
  
  • Create an Admin User in LMS which has the same UserID/Username as the admin used in BizX to run the purge.
  
  
  • Make sure the newly created admin in LMS has the exact same UserID and grant them full permission to all Domains and permission to delete users.
  
  
  • Make sure the LMS admin has an LMS user tied to it
  
  
  • Check that the UserID that is being purged in BizX/EC has a valid LMS User, if not create the user and run the purge again
  
  
  
  


• 2488688 - Unable to Complete "User Permanent Purge" due to "child record found"                   Error Resolution
  
  
  
  • In provisioning Turn Off the "Enable Successfactors Learning Integration";
  
  
  • Log out and back in again on your environment;
  
  
  • Re-run the DRM tool;
  
  
  • Once the purge is successfully completed, re-enable the "Enable Successfactors Learning Integration".
  
  
  
  

Thanks for reading and hopefully this will help save you time when preparing environments for conversions and test cycles.

This blog would not be possible without help of my colleague Dharmjeet Rattan. Thanks again, for all your help.

[PaulT]

Great blog, with some very good detailed information. Since you mention the refresh option at the start, I think its important to add to plan sufficient time for the refresh to take place, as it can take between to 4-5 weeks from start to finish, depending on the number of requests that had already been submitted.

Its also important to check to make sure that the instances are on the same Database before refresh. This is particularly important for partners, as if they have a best practice instance that they refresh to customer instance they will need to ensure their instance is on HANA DB if the customers instance is on HANA DB.

 

[KavitaJain11]

Thanks Paul for your comment.  I agree with you refresh request need to be done in advance (at least 3 weeks) and get the time slot allotted to you to stay on track with schedule.

As per my understanding, Successfactors instance refresh can be done between two instances on different database, whether it’s from Preview to performance or DC4 to DC8 and vice versa as far as they are on same release. Please share if there were any challenges in the past.