SAP SuccessFactors Non-EC BizX - LMS Data Purge using DRTM

[aasthamalik]

Data Purge is an activity where you remove the redundant/obsolete data from system; whereas, Data Retention Time Management is based on a retention period configuration where data only purges after the required/configured retention time has passed.

Both types of purge requests can be found in the Data Retention Management feature and can be used for data protection and privacy as required.

You can find more details about all different types of purge requests in the implementation guide and may also want to refer to another sub-topic explained in a separate blog: Purging Manager & Alternate Manager in SuccessFactors LMS.

Here, I will be focusing on only one of them i.e. Non EC BizX-LMS system setup.

Now, there may be different reasons which you might need to understand for any data purge activity. For example, it may be simply removing old data which is no longer needed by your client or some activities at client’s end leading to company restructuring, etc. Whichever the case may be, based on my experience, I would recommend you to follow this blog if you land in a similar space.

Before we get started, below is the suggested high-level process:

High-level Process (end-to-end)

Once all of the initial agreement is agreed between you (SAP Partner) and the client, following are specifically required for the scenario we are considering (Non EC BizX–LMS):

• Access to BizX instance


• Access to client's provisioning


• Access to LMS environment


• Access to SFTP/FTP

Assuming that you have the all necessary access now, you need to understand how the client’s system works, as for the data purge activities, it’s understood that in most cases the system is already up & running. For this you can go through the LMS workbook, integration(s) between BizX and LMS, RBP (if necessary), other additional relevant documents and also navigate through the development environment (considering it’s a clone of production) to know the system thoroughly.



After you know the scope, you need narrow it down to specifics. The main aim for this part should be to work on below two main areas:

• Identification of Objects: Here, you should know the exact users target population for the data purge as well as other LMS objects to be taken care of like Items, Curricula, Scheduled Offerings, etc.


• Filter Criteria: Finalize the attributes/parameters with client, which you will be using to extract the accurate data from the objects listed post completing the above mentioned part.

Considering you have answers to all questions/doubts in your mind and also have the clarity in the identified target users and LMS objects, here is what you need to understand:

• Using the data purge, you can purge the target users and their associated items on learning plan, current and future registrations, and learning events.


• Objects like Items, Curricula, etc can either be inactivated and/or moved to archive domain (you can create an archive domain), purging such data using Data Retention Management is not part of solution currently, but you can manually (via connectors) make such records inactive or delete them. This way you can ensure which data in all the considered objects can be restrained from use by users. You can carry out this part in the end of data purge to be careful with impacts.

Enable the ‘Data Retention Management’ feature through provisioning and also grant appropriate access to start using this feature. You can find the steps in the implementation guide also shared in the beginning of this blog.

Once the setup is complete you should be able to access:

• Data Retention Management (Create New Purge Request, User Permanent Purge)

Data Retention Management

• Purge Request Monitor

Purge Request Monitor

Data Retention Management (Create New Purge Request)
In specific, to the scenario we are considering (Non EC–BizX LMS), you can follow the following steps:

1. Create the purge request, through the Data Retention Management


2. The request type will be “Purge Inactive User”


3. You can provide a name to this purge request, try to follow a nomenclature that will help you identify specific requests later. Also, its considered as a good practice.


4. Select the purge user criteria from one of the options offered by SuccessFactors-
   Select a single user – One user at a time, it’s a good option for conducting tests.
   Select multiple users – Helps you pick and narrow the target purge population based on their:
   Inactive Time: User status as inactive for 30 days, 60 days, 90 days, 180 days, customize days (to meet your requirement), N/A (if this does not need to be considered).
   Hire Date: Apply the range and users will be selected if their Hire Date falls in the range.
   Country/Region
   Department
   Division
   Location
   Job Code
   The filters set in this option works all together. You can also add multiple rules of similar type.
   Upload a list of users (by User ID or Assignment ID) – Prepare a .csv file that contains the User ID of all the users that needs to be purged.


5. Exclusion criteria can be followed to ensure that target population is correctly set and there is no impact on user with their related information in the system like objectives, learning data, performance forms, etc.


6. Add approvers name, the user who should receive the request to either Approve or Decline. There can be more than one approver, you can make this setting while doing the data retention setup. Also, it is advised to have more than one approver so that no single user can create and approve the purge request.


7. Submit the purge request in two ways, either by scheduling it as a recurring job or launch immediately and the request will be sent to the approver. You can also ‘save’ the purge request if there is a need to come back to it later and make any modifications before submitting.

Purge Request Monitor

Navigate to the ‘Purge Request Monitor’, where you can see the requests for approval, scheduled requests with the preview report and approved requests.

A good feature of Purge Monitor is preview reports. Have a look at the types of previews you can get in ‘Purge Inactive User’. For the relevance to our scenario, the preview reports in use will be ‘UserObjectType’ and ‘SFLearningObjectType’.

Requests Pending Approval

Data Purge Preview Reports

The approved job can be seen and tracked under ‘Approved Requests’.
Note: Screenshot shows the job is completed else it will show ‘In Progress’ status.

Purge Request Monitor (Approved Requests)

 



While the job is running, click on ‘More Actions’ > ‘View Job Details’ to know the exact status of the purge execution.

This will take you to the ‘Execution Manager’, where you will see which part of the purge process your request is currently in.

Note: Below is only depiction of how the progress of the purge request looks like in the Successfactors.

Execution Manager (Purge Job Details)

You may also be interested in the overall purge progress graph by filtering out the Process Definition Identifier as ‘drmRequestProcess’ and Timeframe between last 24 hours to custom date range.

Execution Manager Graphs

Finally, you can also view job details by clicking on ‘View Result’, validate data, analyse the failures and identify the reasons behind it.

Purge Request Manager (View Result)

Hence, by now, you have enabled the Data Retention Management, know how to create the Data Purge Request and also saw how to approve/decline and monitor the purge requests. You might face some errors where you can refer to KBAs available and if still not resolved then raise an incident with SAP.



Considering the purge was successful, you should now run the automatic process to ‘Purge Deleted User Audit History’.

Purging users does not purge the audit / transactional data from LMS, and this is why it is recommended to run this job in scenarios where there should be no traces of purged audit history data. This process can be run after soft purge or permanent purge.

Note: The audit history data is only visible to admins / users with access to reporting in LMS and cannot be seen by users otherwise.

The screen below shows that the job is running:

Purge Deleted User Audit History

Finally, now is the time to run the Data Retention Management (User Permanent Purge):

1. This purge functionality looks for the users purged through the soft purge requests like we have done in the previous point. Hence, this is a pre-requisite to the permanent purge. You cannot directly run the permanent purge.


2. You can create a file with User ID of the users you need to purge permanently.


3. There is no approval workflow / preview reports for these types of requests.


4. You can monitor the job in 'Monitor Job' screen.


5. Once a permanent purge is successfully completed, the users are removed from the Successfactors instance irrevocably. Whereas, if you only do the soft purge, you have an option to Re-activate purged users using 'Employee Import' feature. But, this will not bring back the learning activities associated to the re-activated users.

User Permanent Purge

Here are some tips to have a successful purge execution:

 

• The users must have status as ‘Inactive’.


• The User ID and Person GUID between BizX and LMS must be same for all users.


• By default, the limit to number of users in one purge requests is 10,000. But depending on the volume of the associated data you can always decrease the number of users in each purge request. Hence, create multiple requests to avoid system performance issues / impacts.


• The data purge only includes the users and instructors. The administrators need to be deleted directly in LMS.


• For user initiating a purge request (Admin ID = User ID in LMS), the following workflows in the Learning Administrator role must be assigned to them:  View User, Delete User. If not fulfilled the purge creation request will fail and will show as failed with no approvals.


• For user approving the purge request (Admin ID = User ID in LMS), must have access to workflow ’Run User Data Purge Request Report’​ in LMS.


• Always keep track of the activities, counts, completion, date, execution time, etc related all purge requests.


• Successfactors contains some standard notifications to update you when the purge request is initiated (with link to Successfactors Purge Request Monitor screen where you can Approve/Decline the request), when the purge begins / is completed.


• You can run multiple purge requests at same time, and it would be good if they are all not heavy files, just to save some execution time.


• In case you get errors, try to do complete analysis of the users purged and the users excluded from the purge. There is a list of Data Object related errors you can find in this KBA.


• The process of native users deletion is different and is not suggested for you to do in case you have a platform integrated with LMS. Hence, only use if LMS is a stand-alone system else you are requested to raise the support ticket to SAP and they will happily assist you.

I hope this blog serves a useful purpose. Feel free to drop your queries in comments below, will be happy to answer them.

Happy Learning!