Skip to Content
Technical Articles
Author's profile photo Devi Manthiram

To pre-populate Recruiting operators in the Requisition form when triggered from Position

Requirement:

The common Business requirement from the clients when triggering the requisition from Position is to have the Requisition form filled with pre-populated operators eg Hiring Manager, Recruiter, HR, Financial Controller.

As part of the standard roles available, only Hiring Manager, Matrix Manager and HR Manager can be triggered from the Position. Please refer to the KBA https://apps.support.sap.com/sap/support/knowledge/public/en/2583927 for the mapping of standard roles. When it comes to Recruiting specific roles like Recruiter or Financial controller cannot be mapped directly unlike the standard ones.

I have jotted below the common approaches for populating the Recruiting specific roles that we use along with pros and cons. In this article ,I have focused about Approach 3 where the Recruiting operators can be stored in the Excel and fetched based on the Position parameters .

Approach 1:

To maintain a custom role in EC for the required Recruiting specific role maintained at the Position level and then to have Requisition triggered.

Cons:

  • The roles must be maintained at each Position level which could be a cumbersome process for the existing Positions.
  • Also, for all the newly created positions budgeted or un-budgeted, the Operators must be maintained for each individual Position.

Approach 2:

To create Business rules for Recruiting to default the Operators in the Requisition on the base of the trigger either during initiation or change or save.

Pros:

  • Dependency on EC for creation of custom role is not required.
  • When it comes to house-keeping of data of the Operator’s maintenance is not required at the Position level.

Cons:

  • If the client calls for a Global presence, then multiple criteria parameters of different region or country or location could be overwhelming to accommodate it via Business rules.
  • Changes as part of the BAU can be done only by Admins well versed on Business rules.
  • Operator team cannot be pre-populated as part of the Business rules yet.

 Approach 3:

To create a look-up table to retrieve the relevant Recruiting Operators based on the position defined criteria eg. Location, Business unit or Department.

Pros:

  • For BAU, the end users can directly use the Manage data UI or maintain via the excel of data import and export to make any changes of the Operators’ data.

 Cons:

  • Operator team cannot be pre-populated as part of the look-up option.

Detailing Approach 3:

Look-up Approach to retrieve the relevant Operators stored in an Excel based on the parameters from the position:

In the example below, a step by step process has been detailed for the Recruiter operator to be selected on the parameters of Location and Department from the Position.

Step 1:

1.Create a custom generic object for the look-up table for the Operator i.e. Recruiter

Admin Center -> Configure Object Definition – > Create New

Image 1

In the section ‘Fields’, provide the operator required and the attributes which would determine the selection of the operator for the Position. In the sample below(image 2), the operator is the Recruiter and the attributes to determine from the Position would be Location and department. These fields have been declared as field type User and String for the operator and attributes respectively.

 

Image 2

After declaring the fields, save the object. You can skip the additional sections of Associations, Searchable fields and Business key Fields in the object as it is not relevant.

Step 2:

2.Now that we have the skeleton custom object created, we can populate criteria for the object as   required.

Admin Center -> Manage Data – > Create New

Search for the object name created in step 1 i.e. cust_Recruiter from our example(Image 3)

Image 3

You can provide the details of external code, Department, Location and the Recruiter name as indicated below (Image 4)

Image 4

Alternatively, the template for the object can be downloaded and the information can also be imported via excel as well

Admin Center-> Import and export data

Image 5

Look-up Blank Template:

Image 6

Look-up Template with data populated:

Image 7

The populated data can be imported as well instead of creating the entries manually in the UI.

Step 3:

The last step would be to map the Operator filled from the Requisition template to look-up the value from the defined excel based on the parameters from the position.

Admin Center- >Position Management settings .Click on Integration tab and the rule for mapping fields highlighted in image 8 and edit the existing rule.

Image 8

Add the expression from Image 9 below to refer the Recruiter from the custom look-up based on the Location and Department from the position and save the rule.

 Test Data:

 Navigate to Org Chart and select the position for which Requisition must be triggered.

The Department and location details of the Test data in the sample below contains bshervin as the Recruiter form the look-up below

Image 10

Image 11

Triggering the requisition from Position Analyst 3000931:

Image 12a.

Image 12b.

Requisition 2542 triggered for Position Analyst 3000931 with Recruiter as Ben Shervin(bshervin) :

Click on the window next to Requisition id to see the Requisition form filled with pre-populated Approver as below.

Image 13

 

Inferences:

Based on the crux of the above mentioned three approaches there is no right or wrong method on choosing which way to go about it as mostly it depends on the Client Business processes set-up and requirements.

Some additional insights on the look-up behavior of Approach 3 based on the possible Data scenarios

  • If more than one operator is maintained for the same set of conditions it picks up in the sequence of external code (1,2,3..) maintained in excel
  • In case of more than one operator if the first set of condition fails, then it automatically picks up the next operator maintained provided the condition passes for the second entry.
  • There can be an error message flagged if there are no relevant entries maintained in the excel which can stop the creation of the requisition by itself
  • The relevant operator team cannot be auto-populated from the excel. So, the only workaround for now is to default all the teams required at the Requisition template level and then to strike off whichever group is not required by the relevant Operators

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Melike Irmak
      Melike Irmak

      Hi Devi,

      This soluition (Option3) saved my life 🙂 Thank you very much for this idea. That's brilliant.

      Kind Regards,

      Melike.

      Author's profile photo Devi manthiram
      Devi manthiram

      Hello Melike

      Thanks for the  feedback 🙂

      Glad to hear that the solution helped you !

      Regards

      Devi

      Author's profile photo Priyanka Ramdeep Singh
      Priyanka Ramdeep Singh

      Hi Devi,

      Could it be possible to default operator with recruiting group rather than single user?

      Requirement is to notify about requisition to all users of the recruiting group.

      Once actioned by any one of them (from the recruiting group) the action queue removes from other.

      Hoping for you favorable response!

      Priyanka

      Author's profile photo Devi manthiram
      Devi manthiram

      Hello Priyanka

       

      To the best of my knowledge to default the rec group is still not feasible. The possible two work-around could be

      • To default the Recruiting group at the template level via "Manage Recruiting team settings" if it is just the matter of one group under scope. If its is more than one group that has to be defaulted than the above option will not help unless and until you duplicate the template. Please be noted the group in thsi case would be only for information purposes. The approval action would still need to be done by teh primary user marked in the route map.
      • Secondly, you can create a generic common user " HR admin" and create an inbox which can be shared by the Rec team. By this either via proxy or login , any member of the group can action on the approval. But the catch is the client acquisition team should be comfortable with this approach as there would be no clear cut ownership defined nor clear audit track on who in the group has made this change.

      Hope this helps !

      Author's profile photo Priyanka Ramdeep Singh
      Priyanka Ramdeep Singh

      Hi Devi,

      Thank you so much for your response! Deeply appreciated!

      I have further query to above suggestions:

      Query to point #1: We have only one group which needs to be defaulted for "Sourcer" field. Even the group name is assigned under Manage Recruiting Team Settings > Sourcer > Add Groups to TeamDo you mean all the users of that group will be notified on route?

      As per my knowledge, this will only help in selecting users for Sourcer field, any users who is not part of this group could not be searched for this respective field while creating a new requisition.

      Query to point #2: Apart from no track of ownership and audit, there would be no email notification trigger would happen to users on route. (unless HR admin has valid email id mapped to it)

      Its more like, approvals needs to be monitored manually by proxy-ing every time.

      Kindly advice!

      Thanks,

      Priyanka Singh