SAP Knowledge Base Article - Public

2078700 - Performance Management: Routing - Top 10 Reasons Forms Failed to Route to Next Step, Forms did not move or moved to wrong user or step

Symptom

  • Why are documents not transferring to the correct users?
  • Forms stuck with wrong person. Forms appear to be stuck with "System System"
  • If your issues apply specifically to Manager Transfers in document routing please refer to our solution that speaks to that specific scenario: 2144428 - Routing - Top 10 reasons Forms Not Transferring to New Manager, Failed to Route to Manager

Environment

  • SuccessFactors Performance Management

Resolution

  • These are ordered from the most common causes we find to the least common.
     
  • Note: You should evaluate all options as you might actually have a number of causes. For example if you have 50 forms stuck with wrong person that did not move, you might have some not moved because they were in Get Feedback at the time. Maybe an admin did a manual import on another day and forgot to set correct transfer options to match your template causing some not to move (and they didn't even notice their mistake). Then you also inactivated a manager before transferring the employee forms, and finally some forms simply were never even with the manager to begin with (remembering manager transfer options only apply if the form is with the actual manager at that time.) So although a report shows 50 forms have not moved as expected, it is quite possible there are multiple reasons as to why they did not move as opposed to 1 single system issue that impacted all 50 at the same time.
     
  • Tip: As it possible for forms not to move for the following reasons we recommend that the admin run reports periodically to identify any that became an exception so you can determine those that need to be moved.
  1. Auto-Schedule Forms Not Moving
    1. Are your forms created by the scheduler tool "Scheduled Mass Create Forms"? If so please also read the main scheduler solution along with this solution. See 2088160 - Mass Create Form Scheduler: Forms did not create
  2. Unplanned Alternate Route User Step Added - U Step
     
    1. Alternate User Step Added: An important function of the system exists to prevent a form being stuck with someone inactive or not valid. When the form is routing, at that exact moment in time, our system evaluates your route map and the people and roles involved. Our system is intelligent in the sense that it has built in logic to detect that someone set to get a form is inactive or not valid based on your defined rules.
       
    2. In that case the system is designed to insert a new step and route the form to that step of last known valid user, so that the form does not fall into a black hole, stuck with someone without anyone else being able to access it. This step is called an Alternate Route User Step. Information on this type of step and the problems that can introduce can be found at: 2077339 - Performance Management: Routing - Alternate Route User Step - U Step
       
      • Solution: This can only be resolved by manual intervention since these forms now have a different route map than when launched. The admin should be able route forms via admin tools.

   3. Invalid Values in Matrix Manager, Custom Manager or Second Manager Columns: 

    1. Behavior = Random and ongoing failures. Can result in large numbers of forms not moving as expected in any predictable logic. This is preventable by ensuring only valid usernames exist in these columns.
       
    2. C Steps: Quite often we find the client has a C Step as first step and this is often where the form gets stuck when their was an invalid manager value in one of your manager columns
         
      1. When you check the route map, it says the manager has successfully updated in the future steps, but the form has not moved and is stuck in the C Step.
         
    3. Customers are often diligent in ensuring that all your usernames in your MANAGER column are correct in each import, but many clients fail to be as diligent in maintaining correct and accurate values in the other manager columns that exist > MATRIX_MANAGER, CUSTOM_MANAGER. if you are not updating these columns and have usernames of people who are no longer valid, then this will cause failures and forms will not move for those records. If a person is set as the custom manager of many people then this can affect many forms.
      • Note: If multiple people all have the same invalid matrix or custom manager username in these columns then large groups could be impacted.

   4. Planned U Step

    1. Behavior: Only forms in the U step are affected.
       
    2. If you had a U step built into your route map, please ensure that the username you added in that step is exactly correct and still valid.
       
    3. If your template has the option enabled > Automatic insertion of new manager as next document recipient if not already. This may have added a new manager when you were not expecting that.
       
    4. Solution: You should be able to modify the affected forms route map via admin tools to correct the username to a valid user.
       

  5. Manager Changes:

    1. Behavior = Only forms with manager roles are affected, and it is always at the step specific to the manager.

    2. If your issues apply specifically to Manager Transfers or a manager step, then please refer to our solution that speaks to that specific scenario2144428 - Routing - Top 10 reasons Forms Not Transferring to New Manager, Failed to Route to Manager 

  6.Invalid or Inactive User:

    1. Behavior = Random failures. Impossible to define any logical cause as to why some fail to move and others are ok since this is a data issue. Preventable by ensuring all data changes are properly ordered and users in a route map are set as ACTIVE at time of tranfer.

      Typically these are created by improper transfer options as outlined above.
    2. An Invalid user is any person who cannot log into the system.
       
      1. If you as a user are set as ACTIVE but your manager was set as INACTIVE at the point in time, then you cannot log into the system. If you cannot log into the system our system knows this and will therefore skip you in the route map.
      2. If you are not in the default user group you will be considered inactive and not part of the workflow.
      3. Please keep in mind this logic applies at the exact time of transfer. So while your data file may have you active today, if you were not at the exact time form was routed, issue already occurred.
      4. In RBP, if you do not have "User Login" permission, same with number 1, user will be skipped in the route map.

  7. Failed to make user employee changes in correct order:

    1. Behavior = Random and ongoing failures. Can result in large numbers of forms not moving as expected in any predictable logic. This is preventable with proper approach to data changes.
       
    2. Forms can get stuck with old user and show as "System" when not making correct data changes. Your data changes must occur in proper order to prevent forms from being stuck with the system or the wrong user.
      1. It is important to note that results are relative to the state of users in the system at the exact moment the form transfer is triggered.
         
      2. You resolve these types of scenarios by manually moving forms via route document tools.

  8. Form in Get Feedback Status: 

    1. Behavior = Random failures as its impossible to predict who will have a form in the Get Feedback status at the time a manager change might be imported. Not preventable when using this feature.
       
    2. If a form is in a "Get Feedback" step with a person outside of the standard routing map, then the document will remain with that person and NOT transfer. The person that currently holds the form needs to be identified and asked to send the form on. Only then can the previous user send the form on to the next step.
       
      1. Does your template have get feedback enabled? If it does then this can be a cause for some forms.

  9. Conflicting logic in Field & Route Map Rules:

    1. Behavior = Random unpredictable failures since you cannot control who the form might be with at the time of the transfer yet you have very specific rules at each step as to who can do what. While manager change rule wants to do one thing, your route map rules may be requiring another. The logic that wins is form stays with current person.
       
    2. You have conflicting logic in your forms for required fields and route map steps for step exit or step entry users. Especially when using Iterative or Collaborative steps. Check your route map carefully. Make sure a form will not get stuck with an inactive person if you are defining exist users but form might not be with that person. Example Form is with E in I step at time of manager change but E is not step exit user. Only EM can move form but you inactivate EM before. Now form is stuck with old EM (since transfers only occur if form is IN their INBOX, and E cannot do anything.
      1. Are you using C steps in your route map?
         
      2. Is it just the forms that have a C step that are problematic and is the issue at this step typically?
         
      3. Have support review any Entry & Exit Users you have set in the route map. Think about the logic set and how that impacts transfers for managers under all scenarios. More info on exit users here: 2087291 - Admin Tools: Route Maps - Exit Users and Entry User in Route Map
         
      4. Might it be better not to control exit user to allow free-flow of form transfers as opposed to trying to prevent user controlled moves?
         
      5. Can you consider more steps in route map as opposed to using I steps and C steps that have many people all in the same step? This will result in better document transfers when 1 person within that step is changed.

  10. Form Locked at Time of Transfer

    1. Two possible scenarios that can happen to prevent a transfer are when the form is actually open and being edited by someone else. Obviously if by chance someone is working on a form at the same time the form was to transfer, then those forms will be skipped. This is not a common cause, but can explain why some every now and then didn't move. We have no tools or ways to show if a form was locked at the time.
       
      1. Also note that forms with C steps are more problematic, as they can remain locked for up to 2 hours if a user does not correctly close & save the form to release it for editing and moving. See also: 2078098 - Document Lock for Forms With a Collaborative Step (C-Step)
         
      2. Is an admin performing changes at a time when others are likely to be in the system?
         
      3. Can you perform your changes to later at night?

  11. Form Restored and Sent back From Signaure or Rejected

    1. There is a scenario where you can cause a form to get stuck with an invalid user when routing a form backwards. Please review the steps leading up to your issue to determine if the form had not been sent backwards.
       
    2. If a form is completed or in signature and then sent backwards > However, that person may not want the form and clicks the reject button. The reject action now sends the form to previous step but that person may be someone who has since been set as INACTIVE, so the form becomes stuck. This is an uncommon scenario and will be fixed later 2014.
       
    3. If you do not have the Reject button enabled in your workflow this could not be the cause.

  12. Form Template Public Flag:

    1. Make sure that Template Flag is set to Public. Check this in admin tools on the form template settings.

      Private forms remain with the original manager and will not be transferred with any Public forms. 
      • Required fields should not be problem as a required field is applied only for that role if the form is in their inbox. Therefore if a form is not in the inbox of the role that is required to provide those details then enforcement rules will not apply keeping a form stuck.

Rocking a Form - Moving the Form

If your forms for any of the above reasons are not currently with the correct person the most common way to resolve these are by using admin tools and manually moving the form back 1 step. This causes the system to evaluate the employee data, new managers, route steps, and roles in your form and refreshing the form to reflect the current state of all these variables. Now with the form, people and data in the right state you can move the form back to where you need it.

This is the best, safest and fastest option for admins to manage these exceptions (even if a few hundred develop over time). There is no option Support has to do this automatically for you.

Optimize Your Setup

If your process is causing too many forms to fail to move, then we recommend possible changes to how you manage your Manager Transfer and also adjusting your form template and user import settings to ensure they have optimal settings.

Keywords

route form, failed to route form, form did not route to next step , KBA , LOD-SF-PM-MAP , Routing, Route Maps & Workflows , Problem

Product

SAP SuccessFactors HCM Core all versions