Sometimes customers want to assign more than one matrix manager or custom manager in the Job Relationships portlet in EC. This might occur if an employee is working on more than one project at any one time and more participants are needed in processes such as performance management.
In this blog post I will address how the custom job relationship types are configured and how they behave in the permissions, in workflow and when syncing to the User Data File (UDF).
How should custom relationships be configured in the jobRelType picklist?
You cannot assign multiples of the same job relationship to an employee, therefore, if you want to have more than one matrix manager or custom manager you will need to create multiple picklist values as per the screenshot below.
The picklist external code must be unique and in order for the relationships to be used in the permissions, workflows and sync to the UDF the non unique external IDs must be matrix manager or custom manager:
When we grant the roles in the permission roles we do not see the custom manager 1 or matrix manager 1 custom relationships; we only see the standard roles:
When the permissions are granted, the permission role is assigned to all custom manager or all matrix managers.
What is the impact when permissions are assigned?
In the example below, Larry is assigned in Job Relationships as Project Manager (matrix manager 1) and Mentor (custom manager 1)
If we view the permissions for Larry it looks like this:
What is the impact on workflow?
Only the standard roles are available in the workflow
In our example above multiple matrix managers and custom managers are assigned to the employee.
In the workflow configuration the approval steps are:
Step 1 = HR Admin
Step 2 = Matrix Manager
Step 3 = Custom manager
In step 2 of the example above only one of the matrix managers needs to be approve the workflow before it goes to step 3. If Anna was to approve the workflow it would disappear from Larry’s to-do list.
The system will send the workflows to all matrix managers and all custom managers. It cannot distinguish between custom manager 1 and matrix manager 1.
What does the UDF look like when multiple matrix managers and custom managers are assigned to an employee?
The UDF will show the multiple matrix and custom managers separated by “|”
Other considerations
The Second Manager is the only standard relationship that can be used in the Compensation Module, therefore, it is recommended that it is reserved for that purpose and not used in other processes.
It is not possible to restrict which relationship types a user can maintain in the Job Relationships portlet. If there is a requirement to restrict the user from updating certain relationship types this can be done by raising an error message using a simple business rule.
At the time of writing this blog post it not possible to hide the delete button on the UI even when Delete permissions are not granted in the permission role.
When the user edits the Job Relationship portlet they see the delete button:
However, if they try and delete a record they get this error:
If Delete permission is given to the user it is worth noting, at the time of writing this blog post, workflow is not supported when a relationship is deleted. Refer to the following KBA for more information:
https://launchpad.support.sap.com/#/notes/2987218
Refer to the following KBAs for information on configuration of picklist values and mapping to Employee Profile:
https://launchpad.support.sap.com/#/notes/2079986
https://launchpad.support.sap.com/#/notes/2079991
The key points to take away from this blog post are:
The system will only consider the custom job relationships within the standard permission granting roles and in the standard roles in workflow if the non unique ID of the custom relationship picklist value is “matrix manager” or “custom manager”.
The system will send the workflows to all matrix managers and all custom managers. When multiple custom relationships are assigned the system behaves in the same way as when workflows go to a Dynamic Group.
If there is a requirement to create multiple custom job relationships within SF, the processes in which these relationships will play a part will need to be carefully defined, taking the standard system behaviour into consideration.
I hope this was helpful and thank you for taking the time to read it.
