Guidelines for Loading Candidate Job Applications

This topic describes the considerations for loading job applications using HCM Data Loader.

Considerations for Creating Candidate Job Applications

• Load only currently active job applications. It’s recommended not to load historic job applications for reporting purposes.
• Provide the expected Source and SourceMedium attributes while loading candidate job applications. If you don't provide these, the Source attribute defaults to internal career site and SourceMedium attribute defaults to career site.
• Job applications can be loaded only to the first phase and state of the Candidate Selection Process (CSP).
• While migrating job applications from a legacy system, load to the first phase and state of the CSP and later auto-progress to the target phase and state or manually move using HDL following the CSP rules.
  Tip: Configure a flexfield on the job application to mark it as a migrated job application and then build a fast formula to read the migration marker, which auto-progresses to the target phase and state.
• Loading job applications with offers isn’t supported. It’s recommended to load accepted offers as New Hires or Pending Workers.

User Key

You must provide both these user keys while loading a job application:

• RequisitionNumber
• CandidateNumber

Considerations for Deleting Candidate Job Applications

• A job application can be deleted by using the InactivateFlag attribute. This effects only a soft deletion of the job application.
• The job application has to be in a terminal state before you can delete it.

Considerations for Moving Candidate Job Applications

Using HCM Data Loader, you can move job applications from the current phase and state to a target phase and state. However, the move to a target phase is validated and allowed based on the rules set in the CSP. You can’t move a job application past a mandatory phase or out of a state without meeting the required condition set in the CSP.

You can move a job application to the Offer phase and to states within the Offer phase based on these set of rules. You can also move a job application from the Offer phase to a custom phase between the Offer and HR phases.

Note: The movement of a job application to a target phase and state is recorded as on the date and time of the load.

Job Application Movements in the Offer Phase

The following moves are supported in the Offer phase:

From State	To State in Offer Phase
Any state in a phase prior to the Offer phase	To Be Created Draft
To Be Created	Rejected (by Employer) Withdrawn by Candidate Draft
Draft	Rejected (by Employer) Withdrawn by Candidate
Pending Approval	Draft
Approval Rejected	Draft Rejected (by Employer) Withdrawn by Candidate
Approved	Extended, if the Extend Bypass indicator isn’t selected Note: On moving an offer to the Extended state, the candidate receives the offer and is also notified. Accepted, if the Extend Bypass indicator is selected Draft Rejected (by Employer) Withdrawn by Candidate
Extended	Rejected (by Employer) Withdrawn by Candidate Accepted
Accepted	Rejected (by Employer) Withdrawn by Candidate Post-offer phase and state: This is any customer-configured post-offer phase.
Rejected (by Employer)	Draft, if the offer exists To Be Created, if the offer doesn’t exist
Withdrawn by Candidate	Draft, if the offer exists To Be Created, if the offer doesn’t exist

Job Application Movements in the HR Phase

Once the offer is accepted by the candidate, you can move the offer to the HR phase and Pending Automated Processing state using HCM Data Loader. The offer is then selected for automated processing.

If an error occurs during HR processing, you can move a job application to one of the terminal states, Rejected by Employer or Withdrawn by Candidate, using HCM Data Loader.