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:
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:
Cons:
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:
Cons:
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
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
- SAP Managed Tags:
5 Comments
| User | Count |
|---|---|
| 14 | |
| 11 | |
| 5 | |
| 3 | |
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
