This blog entry is authored Stéphanie Bourgault-Mongeau (https://people.sap.com/stephanie.bourgault) and reviewed by Gobinder Sandhu  (https://people.sap.com/gobi.sandhuFormer Member

Introduction

Position Management and Recruiting Management in SuccessFactors are two close knit features which integrates data seamlessly. Having the ability to a create requisition from a position ease the requisition creation process by automatically filling requisition field values inherited from the position field values hence reducing data entry effort.

One challenge I found while configuring the Position to RCM integration is giving the right level of visibility to the position Org Chart and restricting the ability to create requisition to the right people.

In this blog, we will go over the Position Org Chart permissions as well as highlight the limitations as observed during usage of permissions to control Job Requisition creation on the position org chart. Then, I will propose a cool way to get around it using the business rules!

If you do not know about Position Management to Recruitment Management integration, you might have some difficulty understanding the last part of this blog as I will not cover Position Management to Recruitment Management integration setup as there are already some great blog entries that already do this well.

Position and Position Org Chart Permission 101

For this blog, we will focus on permissions that are related to viewing positions and permission related to requisition via Position Org Chart (we will not cover position creation or editing).

To be able to access and view positions in the position org chart, there are 2 important permissions to give to the users.  First, they need access to the Position Org Chart, and second they need to be able to view positions in the Position Org Chart:

• Access Position Org Chart: Under the Manage Position section, Access Position Organization chart

• View Position: Under Miscellaneous Permissions, Position – View Current or View History.

Note that since Position are Effective dated, you can also give access to change the display date of the position. This will allow the user to go back and forward in time to view what the position org chart looked like  or will look like on a specific date.

Viewing Positions Permissions

For MDF objects, such as Position, by default having access to View the object gives access to view all the fields with the object. However, it is possible to hide fields from the users, by using Field Level Overrides, as highlighted below. In the following example, the users in the role would see all fields in the position except for Job Level and Pay Grade.  Thus, One of the use case for this great feature is to restrict access to the HR related fields on position so that non-HR folks are unable to view such restricted fields.

It is also possible to restrict the Target population of position on a role based on position attributes (for example a role that only see position for 1 of the organization Legal Entity) or based on position relationship (Higher Level Position, Matrix Position, HR Position relationship) by using the options illustrated below:

Position Org Chart and Job Requisition related permissions

Finally, regarding Position Management to Recruitment Management, we have 3 specific permissions. It is very important to note that these permissions are not Target Specific and that it will apply to all position the user can see in the position org chart.

• The ability to view Job Requisition created for a position (note that you need to ability to create requisition form as a prerequisite):

• The ability to create a Job Requisition from the position org chart:

• The ability to select a Job Requisition Template in the position org chart:

So, what’s complicated?

Although, these permissions are easy to understand, I found that it was harder to get the right combination of permission to satisfy clients’s requirement. Here are two interesting cases I ran into and proposed solution

• Case 1: Company XYZ wants managers to view and create requisition for only position underneath him. The company do not want managers to view their own or other employee’s position attributes.

If we would only want managers to view position underneath him, it wouldn’t make sense in the position org chart as all position below him would be shown without links as illustrated below. It wouldn’t be very user-friendly for managers to navigate the position org chart as without him having the ability to view his own position, we lose the hierarchy link between his position and its child positions.

My proposition, to this case, is to create a second permission role for controlling managers’ permissions on his own position. (Manager on themselves). We will use a field overwrite with no access on all the fields except status and start date and grant that role of All Managers. By doing so, it will be easier for managers to navigate the position org chart and create requisition for his child positions.

Solution:

Result:

Though with this solution, arises a secondary problem (explained in Case 2).  The manager could now create a requisition for his own position (as remember, creating a requisition from the position org chart is not a target permission)!

• Case 2: Company XYZ wants manager to view all position but only can create requisition for position underneath him

When you allow managers to create jobs requisition from the position org chart, they can create requisition for all the position they can view. Which could be problematic.

I found a way to avoid this by modifying the business rule that derives the Job Requisition Template for the Position Management to Recruitment Management Integration.

By default, the rule looks like this:

But by adding an If statement to validate that the user is the position’s manager or part of permission groups raising an error message otherwise. In the following example, I validate if the user trying to create the requisition (login user) is the user sitting in the higher-level position of the position he/she is trying to create a requisition for or if the user is part of the permission group Super Admin. If not, I will block the user from doing it by raising an error message (messages are created in manage data). This can be very flexible based on the requirement.

Now, if the manager is trying to create a requisition for a position that he is not the manager or his own position, this error message will show:

Conclusion

To summarize we discussed the permissions related to the position org chart access in context of position management to recruiting management integration.  And in the second part of the blog we went through 2 cases where we set certain restrictions on manager’s ability to see position attributes and create the requisitions.  We achieved it through a business rule. I thought this ‘cool’ rule will be useful for the fellow EC and RCM consultants J .

Thanks for reading and please do send your feedback on the blog 🙂

Stéphanie