2087907 - Data Imports and Exports: Order for Importing User Changes Via Employee Imports - Platform

• Why have forms not launched?
• Why are steps being skipped?
• Why have employees not correctly transferred?
• Why are functions failing for some people?
• Why are scheduled jobs not working for some people at times?
• Why are documents stuck with wrong people? 

It is a common mistake by clients to not think about the order of data changes in your user data files/employee import file.

It is very important that each nightly employee import file is correctly structured, and NOT just an alphabetical/numerical file with all changes added without reordering the employee list to account for the changes needed.

Failure to order it correctly can result in various issues, most that support will be unable to troubleshoot since there is no way for us to know the state of data at each point in the data changes and how that might have impacted other actions. Odd results are expected when the correct order of changes is not applied to your manual or automated imports/user data files.

Here are some of the common issues that can happen when data changes are not done in a logical order.

• forms will not launch > A form cannot launch to an employee who's manager is not yet in system or is inactive. See the example below explaining the order needed to make changes.
• steps skipped in a route map > if a manager change occurs, but new manager is not yet in system or invalid the system will automatically skip that EM skip (or any step where the person is inactive or not valid at that point in time.
• employees not correctly transferred > this will fail if not done in right order: See our main solution that discusses why some forms are not transferring as expected.
• functions failing for some people > random issues relative to above logic will fail.
• scheduled jobs not working for some people at times > due to combination of issues above. Also see this.
• documents stuck with wrong people > see further explanation below.
   
• See related solutions for forms not launching
  • KBA 2144482 - Timing of Your User Data Import Files
  • KBA 2076088 - Troubleshooting_Forms_Failing_to_Launch
  • KBA 2088160 - Scheduler issues

Order of FTP Import Data

Please carefully consider how you order your user import as the SuccessFactors Application will process the file from top to bottom.

Example: There is a new manager; who is also a new employee. You update the employees manager, plus you are also creating a new record for the new manager.

How does our system transfer a document to the new manager, if the file was imported first updating the employees manager to the new manager, BUT the new manager's record has not yet been added to the system because it's near the bottom of your import file? You are in essence assigning an invalid manger to the employee. Result: No documents transfer.

Example: A manager has left and you transfer to a new manager who already exists.

If you deactivate the old manager before transferring the employee and their documents to the new manager, you could end up with forms stuck with the inactive user (the old manager in this case).
  

Example: There is a new manager (Kurt); who is also a new employee. You update the employees (Andy) manager, plus you are also creating a new record for the new manager.

In your import file it is sorted alphabetically in userid Column. Here is crude example of the order your csv file may have been sent to us as >

• From row 1 sorted alphabetical
  andy > existing employee > who used to report to Zach but now reports to Kurt > this row is first in file and will FAIL to update manager column to Kurt as Kurt does not even exist yet in system!
   
• File continues and processes other rows... 
   
  bart > various changes
  curtis > no change 
  kurt > new record > now we get record of new manager, in system but the manager change for Andy already failed. Plus any other actions you probably expected such as form transfers, form launches etc also failed as you tried to execute a manager change at row 1 for a person that was not yet in system.
  zach > final row > zach is set as inactive (if this person had not been inactivated last that also would have led to other various issues, but by chance in this example has no impact since it is final record and its correct to inactivate users last in your files.

Problem: How does our system transfer a document to the new manager, if the file was imported first updating the employees manager to the new manager, BUT the new manager's record has not yet been added to the system because it's near the bottom of your import file? You are in essence assigning an invalid manger to the employee.

Result: No documents transfer. New Forms will not launch. Any other actions expected cannot occur, Documents stuck with wrong people.

Multiple Nightly Files - Best Practice

   The best approach, that results in the most predictable results that can be easier to manage for large companies is to use 3 files. Just send each file 1 hr apart to ensure previous file and changes are completed.

1. In your first file just import all new employees.
   
2. In the second import file, which can be a full file, include all manager changes and general changes.
   
3. The 3rd and final file is processed for those employees that need to be set as INACTIVE. Some companies like to send a file to Inactivate users at the end of the week to be sure that all previous imports and changes in the week were successfully made. (this can help address the rare occurrence where one days files failed to run or import.)
   
4. SuccessFactors can setup multiple staggered FTP imports to fully automate the 3 files.
    

Timing

• Q: What actual times do you recommend we set our import files to run at?
• A: We provide you an indepth best practice example in the following knowledge article: KBA 2144482 - Timing of Your User Data Import Files

Single Nightly File

Based on these realities it is not recommended to just send your employee file always in the same alphabetical order that does not consider the order of changes.

• For optimal results every employee import file is recommended to have 3 sections to it.
  
• Note - the file processes from top to bottom. 
  
• Some people may need to be repeated in the file depending on the actions needed. Example you might have some changes initially for a person early in file, then at end of file you want to inactivate them after all forms and transfers made.

If you will attempt to make all your data changes every night using just one data file then it needs to be constructed using the following logic. Note! Most HRIS systems simply cannot generate a single file auto arranging all your updates in this order!

1. First rows will include all new employees
2. Then subsequent rows will list all employees with any changes
3. Finally you will list all those people to be Inactivated.

Following this logic all changes in the file will refer to records that exist and will allow for the transfer of documents to an existing person/record. (You can reference the same person multiple times in the one file understanding how our system will process each change sequentially based on this logic with the last record in the file setting the final status for that employee.)

data imports and exports, order for importing user changes via employee imports, platform, employee import job, logical order, logic order, how to update, how to import employee, update company people , KBA , csg_q , sf data import files , LOD-SF-PLT-USR , User Management , LOD-SF-PM-MAP , Routing, Route Maps & Workflows , Problem