2144482 - Launching Forms - Forms Fail to Launch Due to Timing Issues - Performance Management

Firstly, we understand that with the many business processes a client can have running at any given time, and the interdependencies you may have with data coming from or to other integrated systems, having total control over when 1 process finishes and another one can start is not always possible. That said, if you do have a measure of control, based on the realities of how the SuccessFactors systems and processes run, here is our recommended approach for data updates and timing that should result in the most predictable results.

• First find out the data center you are on. Our automated processes are relative to midnight of that data center.
• We will use the U.S. in our examples where the Datacenter is relative to Midnight E.S.T.
• Understanding all automatic form launches, and form routing will execute some time after midnight, and this time will vary day to day based on number of clients and forms being launched (remembering we are a shared cloud service)
• Plan to have your employee imports and data changes completed well ahead of 12 midnight EST.
• 8 pm EST: File 1 that contains all new employees to the system. Many common issues are caused when you attempt to include new employees in 1 large file along with all other updates. If you do send just 1 file, ensure all new hires are ordered as the first records always.
  • This file would typically be relatively small, and complete very quickly, but nevertheless, allow at least 15-30 mins between next file in case of unexpected delays.
  • Being a very small file typically also ensures this file gets processed ahead of any others without being queued within or behind large files.
  • This ensures that all employees are already in the system before the system attempts to launch them a new form later on (eg. new hire forms)
  • If 8pm EST (5 pm PST is simply too early, you could try alternative time of no later than 11 pm EST - 8pm PST)
• 8:15 pm EST: File 2 - All your data updates, including manager changes, and other general data updates
  • This file would trigger forms to move to new managers, and also any new people. Doing it after the previous file prevents issues with forms not launching or not moving because a new person was not yet in the system.
  • This process could take some time to run and complete as it takes physical server processing time to evaluate every change and physically move forms from the inboxes of 1 user to another etc. Therefore the time to complete is exponentially longer with the more people being updated in each file.
  • If 8:15 pm EST (5:15 pm PST is simply too early, you could try alternative time of no later than 11:15 pm EST - 8:15 PST)
• 9 pm EST: File 3 - All people you plan to set as INACTIVE in the system
  • Only once all the other processes have completed should you then attempt to set anyone as INACTIVE. Including INACTIVE records at any earlier time will cause various logic issues where forms may not launch or route as needed as someone central to that form is already detected as INACTIVE.
  • If you plan to send in just 1 nightly file that include updates and INACTIVE records, then you need to ensure all people to be set as INACTIVE are moved to the bottom of the file and processed last.
  • If you cannot control the way this file will be sorted (often its automatically sorted by username) then you should send 3 separate files as we explain here.
  • Doing it at this time and BEFORE the nightly automated jobs that will run after midnight, to launch new forms or mass move forms will ensure that random logic issues will not occur where forms fail to launch, fail to route, or get stuck with inactive people.
  • If 9 pm EST (12 pm PST is simply too early, you could try alternative time of no later than 11:30 EST - 8:30 PST). Some clients find it best to just send 1 file at the end of the week for all INACTIVES so that in the event a process had failed to run on any one day, it allows extra time for missed processes to catch up and complete, before you make someone inactive.
• Note: Clients with large employee counts ( > 20,000) may need to widen these windows of time if you still see random failures and issues with forms launching or not routing as needed.
  • Golden rule is to stay away from scheduling any processes to run around midnight, which is when we typically perform maintenance which may impact processes, and when other processes might automatically start, so plan to have all daily data updates completed well ahead of midnight.
  • Never schedule processes to run from Midnight to 3 am relative to your datacenter, as those jobs would be most impacted by other processes.
  • Also, scheduling data updates to run during peak daily activity is not best practice, as people may naturally be in the system looking at forms, which also would prevent manager changes or form routing to complete correctly.
• Now that all data changes have been imported and completed in the most optimal logical order, your system is in optimal state to allow forms to automatically launch after midnight, and allow for the routing of forms to occur without issues. Depending on how many forms need to be launched on any given day, this process could take just seconds or minutes to complete on a typical night, but may take many hours for larger clients when you are launching new forms to everyone, or it is at a step where everyone's forms will be automatically routed to next step. Since no data changes will now occur during this time, it won't matter how long it takes for all your forms to launch or route. Problems should be reduced or eliminated.
• Any issues that may still exist would now be more likely due to user error and incorrect data that is within the clients control as opposed to logic system errors.