How to better control Job Requisition creation from the Position Org Chart using permissions and business rule
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
Stephanie,
Thanks for the detailed blog.
Very helpful.
Regards
Raj
Thanks Rajasekar!
Awesome blog Stephanie. It covers all aspects of position org chart.
Thank you for sharing.
Thanks Ankit!
Stephanie,
Thanks for the detailed blog,
Regards
KP
Thanks Venkata!
Thanks Stephanie, I had a similar ask for one of my client and I tried your 2nd option and it worked just great. Thanks for the valuable information.
Regards
Ajay
Thanks Ajay, I'm glad that you could proposed the solution to your client.
Great tip, Stephanie! You have a very clear communication style which is extremely helpful!
Great article. Just received a change request from the client to enable requisition creation from position org chart only, luckily found the article.
Thanks
Sharad
Thanks for this blog Stephanie, it underlines that requisition creation process becames very tricky to configure for a consultant when EC-RCM integration is enabled.
There are truly a lot of different cases from clients to hide something from someone.
For me it was a big surprise that requisition icon that appears on a position couldn't be hidden from position owner. For business users it's critical as manager A (who can initiate requisitions) will definately see that his/her manager created requisition on his own (A's manager) position, so that it will be shown that company wants to move him away.
Hi https://people.sap.com/stephanie.bourgault
Thanks for your post.
I followed the steps above but as it shows in the image below the requisition icon keeps appearing to the position owner. I think I didn't undestend if you mention the solution for this behavior in your post. Actually I need to show all levels (above/below) in the position chart but only shows the icon for the positions bellow (excluding self).
Thanks!
Hi Stephanie
We are just implementing SuccessFactors Recruitment and I am researching the various ways a requisition can be created. This is a great article. How is the Position to RCM integration set up, is it using IT1107 Vacancy Infotype?
Kind regards
Julie
Hi Stephanie,
After I create the requisition from position org chart, the originator is defaulted to SFAPI, instead the one who created the requisition. Could you please guide me, where this setting is made.
Thanks,
Aswini
Very nice trick specifically for scenario 2 🙂
Hi Stephanie,
Thank you for this information, it is very useful and saved my life 🙂
Kind Regards,
Melike
Hi Stephanie,
This is very insightful and useful to provide a solution to a real business use case - indeed I have applied this to my customer!
Also I can share another real business use case that my customer has requested:
Some organisations have a BU Rep kind of role where they are in charge or creating Job Requisitions (especially Evergreen reqs) for their entire Business Unit. They are most definitely not a Recruiter or a Manager of the position, but are tasked to kickstart certain BU activities.
Let me know if anyone need the details on how to set this up
Best Regards
Ernest Lin
Hi Ernest
I would be interested in knowing your solution for your BU scenario. We have a similar request.
Regards,
Lynn
Hi Lynn,
Somehow I cannot attach a screenshot here!
To allow a BU Rep user to be able to create Job Requisition for Positions of only their Business Unit, the concept is similar:
This way, the users in your BU Rep permission group can have the option to select your Job Req Template (thereby able to Create Job Requisition) for only certain Position.Business Unit with the except of other Position.Business Unit.
Let me know if this helps! This works for me.
Best Regards
Ernest