The proper use of Matrix Manager (EX) role is for when a person has a dotted line relationship to the manager. It is often used to represent the employee reports to a manager other than their direct manager for a special project or business need for a period of time.
- the role code for matrix manager is EX.
- EX can be used in route maps to ensure the form is routed to the persons matrix manager. Note, if you have multiple managers listed then it goes to the first person in the list. if you want it to apply to all all matrix managers then use EP.
Matrix Managers are set in the system by importing the usernames in the column MATRIX_MANAGER.
- A person may have multiple matrix managers if working on many projects for examples. In your import file, in the MATRIX_MANAGER column enter usernames separated with the pipe. john|mary|bob.
- Field is limited to 100 characters.
EXM = employees matrix manager's manager.
EP = all matrix managers for a person: More info at Manage Users: How to use the EP Role (All Matrix Manager's)
The Custom Manager role is a role that has no specific purpose other than to provide clients with a manager role other than the direct manager EM. This enables the client to leverage this custom manager role in more flexible ways than what the regular manager hierarchy might otherwise provide.
- Custom Managers are set in the system by importing the username in the CUSTOM_MANAGER column.
- The role for custom manager is EC. Note, if you have multiple managers listed then it goes to the first person in the list.
- EC cannot be used in route maps. If you try to use it in a route map you will get the error: "Changes Failed: You have entered invalid custom roles."
- A person may have multiple custom managers. In your import file, in the MATRIX_MANAGER column enter usernames separated with the pipe. john|mary|bob.
- Field is limited to 100 characters
For more detailed information specific to Custom Manager please see: > Manage Users: What is "Custom Manager" in the application?
Clients must treat the data imported into the matrix and custom manager columns with as much importance as they do the regular MANAGER column. It should be maintained and kept accurate and up-to-date as you do for data imported into the MANAGER column.
It is a system record that is actively used in day to day process, and is validated in each user import, and user update, so you should remove any usernames in these columns that are no longer active or when the person no longer reports to this matrix or custom manager. Failure to do so can lead to issues with form routing and launching.
Some clients hijack these columns to assign an ad-hoc relationship to someone for the purposes of form routing or reporting. For example, you have some people you want to include in the route map, but they do not map to the standard manager relationships. For the purpose of your performance cycle you upload all these people into the matrix manager column, then add the EX step to your route map so the form will go to them.
Another common workaround is to put names in these columns so that you can assign the people certain reporting permissions.
While both scenarios are possible, neither are using these fields and roles for their intended purposes, so please carefully consider any alternative use of the system before making this your standard process. In the future if you have a need to use the fields for their proper purpose you may be unable to because it would not be easy to change the system and re-educate your managers and users on the features they had become accustomed to.
Invalid Values in Matrix Manager, Custom Manager or Second Manager Columns: PMT-8849
- 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.
- Quite often we find the client has a C Step as first step and this is often where the form gets stuck.
- 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.
- 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.
KBA , sf data import files , LOD-SF-PLT , Foundational Capabilities & Tools , How To