Skip to Content
Product Information
Author's profile photo Abisheg Suresh

Automatic Requisition update based on Position field changes

This article shows how fields within a requisition can be updated automatically once a position has been updated.

There have been many a times that organisations have updated the position fields after a requisition has been created (or manually created and position detail added later) – resulting in either a manual activity to keep the requisition in sync or leaving them be out of sync until EC/Onboarding kicks in.

With this article the aim is to show how to keep the requisition in sync with position.

Pre-requisites:

For my example, I have assumed the Company (Legal Entity), Division (Business Unit), Department and Location to be the fields that need to be kept in sync. However, any field supported in the usual business rule from position to requisition creation, can be used.

Let us assume that I have created my requisition from position management – by click on create requisition from within the position, and then gone ahead with the usual route map for approval and now that the requisition is live. Through the course of hiring, the organisation has decided to move this position to a new department and location. Now according to the standard build, the requisition will be out of sync compared to the position and hence needs to be updated – and here comes business rules and Integration Centre!

My existing position when the requisition was created:

 

Position%20details%20when%20requisition%20was%20created 

Position details when requisition was created

My requisition when it was created:

Requisition%20details%20when%20first%20created%20from%20the%20position

Requisition details when first created from the position

Now, the position after the org changes (notice department and location have been updated):

 

Position%20details%20after%20the%20org%20changes

Position details after the org changes

 

 

 

The business rule used to map the fields:

Business%20rule%20for%20mapping

Business rule for mapping

Config update in Manage Rules in Recruiting:

I have added this as a save rule that way we can trigger the rule on regular intervals using Integration Centre.

Manage%20Rules%20in%20Recruiting

Manage Rules in Recruiting

 

Integration Centre:

I have used SuccessFactors as the source and destination (Odata V2, scheduled job). The started entity in this case is Job Requisition.

You only need to map the req id (please note it is better to always use this only for approved and/or closed reqs, as open reqs might not have all the fields populated).

Requisition%20ID%20mapping

Requisition ID mapping

Also, I would only want the requisition to be updated if the linked position has been updated. For this condition, in Filters, I have added the ‘Change Date’ of the std_position_obj within the requisition to be checked with the last run date/time.

Filters%20in%20Integration%20Centre

Filters in Integration Centre

For scheduling, you can only run this once everyday or weekly or monthly or yearly.

 

Requisition after the Integration Centre job run:

Requisition%20after%20Integration%20Centre%20job%20run

Requisition after Integration Centre job run

Points to note:

  1. Std_position_obj is a pre-requisite like mentioned before. This automated update will not work with any other position options within the requisition.
  2. Preferably use this integration only for approved and closed requisitions as open requisitions which are pending approval, sometimes do not have all mandatory fields filled in, which will result in Integration centre throwing an error.
  3. Care should be taken, and detailed discussions need to be held with the talent acquisition team before implementing this solution as the business rule is a ‘On-Save’ rule, which means even if business users are tying to update any field within the requisition, this rule will be triggered. So, if a recruiter/recruiting operator, has a business reason to change some of the fields within the requisition to not match the position, this rule will make sure it reverts it!
  4. With Integration Centre scheduling – Daily executions are not supported as this requires the update/last modified date to be in the requisition, however in our case the change is in the position rather than the requisition.
  5. Intelligent services, from what I have checked this cannot be triggered through this because
    1. ‘Position Update’ – The base object in intelligent ‘services is automatically assumed as ‘Position’, but the position object does not store requisition details, so wouldn’t be able to map for requisition to be updated.
    2. ‘Requisition Update’ – The requisition is not updated in the first place; the position is updated for which we require the position to be updated.

 

Hope this helps in understand the steps required to automate the updates to requisition when a linked position is updated. Please share your feedback/ views on the same. You can find more details on Recruiting questions and answers from other fellow community members over here: All Questions in SAP SuccessFactors Recruiting | SAP Community

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Karen Perez
      Karen Perez

      Good one, Abisheg!

      Author's profile photo Abisheg Suresh
      Abisheg Suresh
      Blog Post Author

      Thank you very much Karen 🙂

      Author's profile photo Angela Pullano
      Angela Pullano

      Great solution to automate these updates!

      I do want to call-out that updates of position info to requisition may not always be appropriate depending on what was changed and the regulations in your country.

      For example, if the position's job code/title changed, it would not be appropriate for us in the USA to have that update an open requisition as the candidate requirements/candidate pool may be different.  We also want to ensure that the external posting location is not changed after posting (again, different candidate pool).

      For this reason, I configured our update rule to be triggered manually as an on-change rule on the position field on the requisition.  The position field is view-only to recruiters but editable to system admins.  This allows the admin to review what the changes are to determine if it is appropriate to update an existing open requisition, or if the recruiter should be directed to close the existing requisition and create a new one.  We simply re-select the same position in the requisition and it updates the corresponding fields we have configured in the rule.

      Best regards,

      Angie

       

      Author's profile photo Abisheg Suresh
      Abisheg Suresh
      Blog Post Author

      Hi Angela,

      Thank you very much for the comment, really appreciate the details shared.

      I agree, this solution although possible, should be used with utmost care and consideration around processes and local regulations.

      There are many ways this solution can be used.

      • Run it as a daily job
      • a one-off job during org restructure
      • create multiple IC jobs and run it every hour with the only filter being 'open' jobs
      • or like you had mentioned, use the rule and leave it as a onChange rule.

      All of these options have their own pros and cons beyond the system, hence there needs to be a careful study around all before implementing it.

       

      Many thanks

      Abisheg

      Author's profile photo Rinky Karthik
      Rinky Karthik

      Hi Abhisheg,

       

      Nice blog and thanks for sharing this info with the bigger community. This was one of my To-Do list for Blogs, LOL! I am glad you have covered it now.

      Angela Pullano  ,

      thanks for sharing your feedback.

      What do you refer to by "if the position's job code/title changed, it would not be appropriate for us in the USA to have that update an open requisition as the candidate requirements/candidate pool may be different."  Ideally, if a requisition was initiated for a specific vacant position, the candidate was supposed to be hired for that particular position attributes. If a position attributes change, and If the business requirement for the candidate isn't aligned with the changes, that should require a different position, correct? Ultimately, the candidate will come back and tie to the position, the requisition was initiated from. Maybe I have misinterpretated your statement, it will be helpful if you can explain?

       

      Also, it's not a common practice for every customer in the USA but maybe just a few.

       

      Rinky

      Author's profile photo Angela Pullano
      Angela Pullano

      Hi Rinky,

       

      I will do my best to clarify!

      Anytime a position/job requisition is changed in a manner that would affect the qualified candidate pool, the requisition should be closed and a new requisition created.

      • change in education requirement
      • change in experience requirement
      • job role change
      • working/job posting location change

      Using the same requisition in the above scenarios will result in a candidate pool that is not really equal in competition for the same position and may result in candidates that previously applied no longer being qualified (but did meet the requirements at the time of the original posting), or candidates that viewed the job previously not having applied, but would have, if it had been posted with the new requirements.

      Changes to a position that only affect back-end administration but would not affect the external job posting are fine to use the original job requisition and posting/same candidate pool.

      • cost center changes
      • correction to other org data assignments
      • supervisor change

       

      Best Regards,

      Angie