2144428 - Routing - Top 10 reasons Forms Not Transferring to New Manager, Failed to Route to Manager - Performance Management

SAP Knowledge Base Article - Public

2144428 - Routing - Top 10 reasons Forms Not Transferring to New Manager, Failed to Route to Manager - Performance Management

Symptom

Why are documents not transferring to new manager?

Forms stuck with wrong person.

Forms appear to be stuck with "System System". Note: This is the user account all automated transactions are logged against. Typically it is not physically with "system" but actually still with the inactive user or old manager.

Environment

  • Performance Management

Resolution

Trigger Events for Document Transfers:

There are a number of areas in the product that can trigger a document transfer. It is good to understand just what events can trigger a valid transfer to begin with in case another admin is triggering one of these events. They are:

  1. A manual change is executed via Admin tools > Manage Users > Documents Transfer
  2. Automated FTP employee file import. With this option your transfer options are configured at the time the FTP process was setup and will not change until requested.
  3. Manual employee file import. With this option, since it is possible for the user to use different settings on every import, differing results may occur.
  4. Company Change Engine: In addition to the standard manager changes that can trigger document transfers, the employee change engine can also be configured to execute a documents transfer on other triggers such as: Jobcode Change and Location Change.

 

Resolution

 These are ordered from the most common causes we find to the least common. The least common explain 1 offs and small numbers of issues, with the more common causes being responsible for possibly even hundreds of forms not moving for large companies with thousands of forms and many active changes.

Note: You should evaluate all options where the behavior described is similar to what you are reporting, 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.

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 in auto-routing that you determine need to be moved.

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.

 

  1. Change Engine:
    1.  Behavior = All forms will lock to old manager while enabled at the time the manager transfer is applied.

    2. The most common cause is because you froze the form using the Change Engine. Note once locked a form will not unlock. Turning change engine off after forms are locked will NOT unlock them. A workaround to unlock forms locked to the old manager is to resave the route map from admin tools. Click here for more info on Change Engine.
      1. If the client is using Change Engine at time of launch the route map for each document will now contain  <freeze-user-to-role><![CDATA[true]]></freeze-user-to-role>

        Internal Note: Go to provisioning > modify doc route map > doc id >  you will see <freeze-user-to-role><![CDATA[true]]></freeze-user-to-role>

        If this is in the route map xml then confirm with client that form is correctly working as designed based on change engine settings.

  2. Invalid Values in Matrix Manager, Custom Manager or Second Manager Columns: PMT-8849
     
    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.
      1. Quite often we find the client has a C Step as first step and this is often where the form gets stuck.
      2. When you check the route map, it says the manager has successfully updated in the future steps, but the form has stayed with the old manager in the C Step, and that old manager can not move it.
    2. 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.
    3. Note: If multiple people all have the same invalid matrix or custom manager username in these columns then large groups could be impacted.
       
  3. Form Template Level Transfer Options Conflict with Import Settings:
     
    1. Behavior = For any import done none of the forms will correctly transfer. If you are performing both manual employee imports and automated FTP imports then some might transfer correctly while others fail. Typically that is because the manual import settings were not quite right.

    2. Your Form template transfer settings must match same setting in the FTP daily import. Also if doing manual imports the transfer options needed to be correct to match your actual template transfer options. This issue is discussed in detail in this solution.

      1. Support should review with you if all your templates, ftp user import, and manual imports have the right settings for document transfers.
      2. Note that changing your transfer options in the template or import AFTER you already performed the import will not fix existing forms that are stuck. You will now need to transfer employee back to old manager, and transfer them back to new manager to trigger proper transfers. (or rock the forms as explained below)
         
  4. Form Not Actually in the Inbox of Manager:
     
    1. Behavior = No forms transfer as expected or only some forms transfer whereas others transfer fine depending on what transfer rule is in play.
    2. Do you realize that the "Inbox Manager Transfer." option only applies IF and WHEN the form is actually with that manager in their inbox at the time of the transaction?  Please see our solution that explains this feature.
  5. Invalid or Inactive Manager:
     
    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.

      Typically these are created by improper transfer options as outlined above.

       
    2. An Invalid manager is a person who cannot log into the system. If you as an employee do not have an ACTIVE manager, 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. Similarly, if you as a manager have a manager above you who is INACTIVE, then you also can't login to the system so we will not transfer a document to you.
    3. Major issues that occur when data changes are not done in the correct order are
      1. New manager not in the system at the time the employees data row is processed. (even though the new managers record is in the file it was not entered first but later in tile)
      2. Old manager is set to inactive in the file before you transferred the the forms to new manager. Now forms are stuck with the inactive manager.
      3. You must structure all employee imports and data changes in a logical order. See here for more information
        1. Are you using multiple import files for new employees and deactivating old employees? (recommended options)
        2. Or are you doing it in 1 file and if so are you ensuring it is ordered in 3 sections?
      4. You resolve these types of scenarios manually by reactivating any users. Also if it is in old managers inbox you can either temporarily make them manager again, or manually route form to a previous step at which time the old manager will be removed and corrected to new manager. (sometimes referred to rocking the form to trigger role updates).
  6. 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.
      1. You resolve these types of scenarios manually by reactivating any users. Also if it is in old managers inbox you can either temporarily make them manager again, or manually route form to a previous step at which time the old manager will be removed and corrected to new manager. (sometimes referred to rocking the form to trigger role updates).
         
  7. Timing Conflict Between Automated Imports + Scheduler Launch
     
    1. Are all your employee imports and data changes completed each night before the scheduler process runs? If you have data updates happening at same time as form launches then various random issues are possible. See > Performance Management: Launching Forms - Forms Fail to Launch Due to Timing Issues
  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 back to the old manager. Only then can the old manager send the form on to the next step, which may or may not be to the new manager depending on your routing map and the transfer options used in the transfer. 
      1. Does your template have get feedback enabled? If it does then this will likely be a cause for some forms.
  9. Unsupported Manager Role
     
    1. Behavior = Consistent failure for forms for a specific role not to change, typically at the step that manager role is in the route map.
    2. In the SuccessFactors application the term "Manager" as it relates to "Manager Transfers" only applies to EM, EX, EH. It does NOT apply to other manager roles such as second level manager (EMM), or other manager roles. (EH EA EC etc.)
    3. For these other manager roles forms will remain with them as the system treats them like any regular person. If you want to transfer a document for these people you will manually need to route it using the routing tool in Admin Tools.
  10. 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 (maybe old manager)
    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 or old manager if you are defining exist users but form might not be with that person on a manager change. 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.
      4. Might it be better not to control exit user to allow free-flow of manager 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
      6. For customer who do not have EC enabled, issues with Manager/Matrix Manager change in C-step can be avoided by executing all changes via bulk user import as this this type of import job has a setting that controls the correct transfer in C-step.
  11. 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 your FTP or manual user import is done, 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..
      2. Is an admin performing employee changes at a time when others are likely to be in the system?
      3. Can you change your automated FTP import time to later at night?
  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. This flag has no impact on the route map however, if there is any EM steps in the route map that have not been completed, these EM steps will reference and route to the new manager at that time.
       
  13. Manager Transfer Performed for Enterprise Client Using Manage Users or Document Transfer With Form in Signature Step
     
    1. PMT-8442 Known issue where client uses Manage Users or document transfer option to update manager record for a form that is in signature step. Followed by the recipient of the form rejecting the form backwards. The result is the form gets stuck with new manager who has no send button.
      Note: Enterprise clients should not even use "Manage user" option in admin tools. This link is typically only enabled for PE clients.

    2. Can be resolved by rocking the form backwards and forwards.

* 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. Also you may need to consider a change to your route map if you have a setup where C-Steps or Entry & Exit users cause too many forms not to move.

Keywords

route form, form not transferred to manager, document transfer , KBA , LOD-SF-PM-MAP , Routing, Route Maps & Workflows , How To

Product

SAP SuccessFactors HCM Core all versions