11Candidate Hiring and Onboarding
Candidate Hiring and Onboarding
Candidate Hiring
Hiring a Candidate
The candidate must be at the completion status of a step.
The candidate selection workflow must include the Hire step.
A user type permission grants user access to this feature.
In the Candidates list, select a candidate.
Select Bypass in the More Actions list.
Select Hire in the New Step field.
Complete mandatory fields.
Click Save and Close.
The candidate is hired without going through all the steps of the candidate selection workflow. The status of the candidate is Hired.
When the last position of a requisition is filled, the requisition is automatically unposted from the company's career sections and intranet, and the requisition is no longer displayed in the requisition list. Also, the step for remaining candidates is changed to Rejected.
Hiring a Candidate More than Once for the Same Requisition
A setting allows the activation of this feature.
The action can only be performed for one candidate at a time and on hourly requisitions (this is the only type of requisitions for which the selection process can be restarted).
The action can be performed on a candidate with the following status: Rejected, Declined, Offer, Hired.
The action cannot be performed if the application is flagged as deleted, and if the management step (RSOffer step) is part of the workflow (active or not active step), if it brings the hiring manager to a restricted step.
The requisition must be active (it cannot be canceled or filled).
The candidate must not be disqualified for the application or for his/her profile.
In a candidate list, select a candidate file.
In the More Actions list, select Reset Selection Process.
Click Done.
The candidate is now back into the selection process and can be rehired.
Recording that a Candidate was Hired
In the Candidate file, select Move... from the More Actions list.
In the Move window, select the Hire step and Hired status.
Click done.
The Hired status is displayed in the candidate list indicating that a candidate has completed a selection process and is ready to be hired.
Cancelling the Hiring of a Candidate
A user type permission grants users access to this feature.
The status must be Filled.
In the requisition file, select Reopen Requisition in the More Actions list.
Select the option Cancel the hiring of candidates.
Click done.
Candidates previously hired for the requisition will no longer be hired.
Contingent Hiring
Contingent Hiring
Contingent hiring is used to hire people when needed and for a limited period of time from a third party agency specialized in submitting pre-qualified workers. Contingent hiring may include part-time, temporary and contractor work.
The Contingent Hiring solution is meant to support the first sourcing part of the typical contingent process, where specific requisitions are created and invitations to refer candidates are performed. Once the candidate submitted by an agent is selected for a limited term, there is usually a time sheet and billing process involved, not done within the Recruiting Center.
When the Contingent Hiring feature is activated and configured by the system administrator, users can start acquiring contingent workers. When creating a requisition, users can choose a Contingent requisition type which offers specific contingent functionalities like a candidate selection workflow built for contingent hiring, a Contingent Terms section, supplier invitation to submit candidates using the agency portal, confirmation of availability and specific candidate ownership rules, different from the rules associated with other agent submitted candidates. Once the candidate is hired, the system does not provide additional support like time sheet and billing. To feed such systems, integration with worker information, billing rate and suppliers (agents) can be done upon hiring.
Contingent Hiring Process Overview
Below are basic steps performed by a recruiter to hire contingent workers.
Creating a Contingent Requisition
When creating a requisition, recruiters should choose the Contingent requisition type because it provides specific functionalities like a candidate selection workflow built for contingent hiring (less prescreening, interview, or background check), and contingent specific fields such as:
Target Start Date: Date when the worker will start working on the job.
Target End Date: Date when the worker will complete its mandate on the job.
Start Time: Time when the job will start, default based on the offer start date setting. Such start time is modifiable and is saved based on the current user time zone and converted upon display on the current user time zone.
End Time: Time when the job ends every day, based on the current user time zone.
Maximum Hourly Rate: Maximum hourly rate allowed for the current requisition.
Requested Hourly Rate: Requested hourly rate used to inform the agent about what should be submitted.
Estimated Expenses: Expenses that can be added in order to calculate the total estimated cost.
Estimated Labor Cost: Hourly rate paid to the agency multiplied by the estimated number of hours per days, times the number of estimated days. This is only an estimation based on a fix number of hours per day and a fix number of days per week.
Estimated Labor Cost and Expenses: Total estimated cost by adding the expenses to the estimated labor cost, when the expenses are reimbursable.
Expenses Reimbursable: Checkbox field used to decide whether or not the expenses are included in the Estimated Labor Cost and Expenses field upon clicking the Calculate button or saving the requisition.
In the requisition Contingent Terms section, a Calculate button is available. When the Calculate button is pressed, the system calculates the value of the "Estimated Labor Cost" and "Estimated Labor Cost and Expenses" fields. This is based on the number of days the worker is hired based on the start date and end date, using the number of days per week (Calculator Default Daily setting), multiplied by the number of hours per day (Calculator Default Hourly setting). This number of hours is then multiplied by the requested hourly rate for the "Estimated Labor Cost" and will add the expense to this into the field "Estimated Labor Cost and Expenses" if the Expenses Reimbursable field is checked.
For details, refer to Creating a Requisition.Posting a Contingent Requisition
Once the requisition is completed and approved, it can be posted.
The only place where to send contingent requisitions is to agencies. In the contingent requisition Posting and Sourcing tab, the recruiter can only select agencies (all other options are never visible). There is no possibility to post directly to career sections and let candidate apply. The entire sourcing process depends on the agents submitting candidates.
The invitation process is slightly different for contingent requisitions. The invitation is done at the agency level, not at the agent level (for all other staffing types, each agent is invited individually). Invitations are sent to all matching agents associated to the selected contingent agencies, based on their Organization-Location-Job Field (OLF).
When the posting process is completed, selected agents receive an invitation to refer a candidate. Agents then go to the agency portal and submit their candidates.
For details, see Inviting an Agent to Refer a Candidate.
When posting contingent requisitions, users are able to post to non-contingent agents and the MWBE field is not displayed for contingent agents. Users should put the word Contingent and the missing field information in the agency name.
Viewing Referred Candidate Submissions
Once candidates have been submitted, the recruiter can review candidate submissions.
Ownership can exist at the candidate submission level for contingent workers. Once the general ownership is expired, another agent can submit the same candidate again on a new requisition. But while manually changing the agent in the candidate or submission file in the Recruiting Center, the referring agent is changed everywhere, impacting existing requisitions where another agent submitted the same candidate originally. Customer should not change the agent for candidates being active on at least one requisition with another agent.
Contingent Hiring - More Actions
Editing a Contingent Requisition
The edition of a contingent requisition is based on standard permissions and field security.
The requested hourly rate can never be saved above the maximum hourly rate. This is why we recommend to only allow some user types to change the maximum hourly rate.
Some contingent fields cannot be modified once the requisition is posted:
Estimated Expenses
Estimated Labor Cost
Estimated Labor Cost and Expenses
Expenses Reimbursable
Requested Hourly Rate
Duplicating a Contingent Requisition
When duplicating a contingent requisition, certain fields are not duplicated.
| Requisition File Section | Field Not Duplicated |
|---|---|
| Logistics - Profile - In Contingent Requisition | Target Start Date |
| Logistics - Profile - In Contingent Requisition | Target End Date |
| Logistics - Profile - In Contingent Requisition | Start Time |
| Logistics - Profile - In Contingent Requisition | End Time |
Capturing Contingent Fields
When creating a candidate file, it is possible to capture contingent fields placed in the create candidate flow. Contingent fields are submission specific, thus only available for configuration into job-specific capture flows.
Contingent specific candidate fields are specific to each submission and as such, are visible or modifiable only within the submission file. For details, see Candidate Fields to be Used for Contingent.
Contingent Hiring - Exceptions to Standard Behavior
Important information regarding the behavior of specific features if used with contingent hiring.
| Feature | Exception |
|---|---|
| Sourcing and posting | For contingent requisitions, sourcing is achieved exclusively through invitations sent to agents. There is no direct posting to career sections. This is because contingent hiring process relies on the association between a worker and an agent, and such association is requested at all time to correctly support contingent. To be able to invite an agent, the agent must be associated to an agency portal. |
| Matching candidates | Although matching candidates is allowed, matching a non-contingent candidate to a contingent requisition will generate a worker without an associated agent. This situation, which is probably an exception, can be corrected by adding the agent once the candidate is matched. Matching a contingent worker to a non-contingent requisition is also allowed, but can generate surprises to those workers since they might start to receive direct correspondences if they have an email in their candidate file (for example, invitations to complete their file and overwrite values entered originally by the agent). This should be considered carefully to avoid generating surprises to candidates. This might also look as an attempt to bypass the agent if this was not discussed previously. |
| Number of positions | For a contingent requisition, the start date and end date are managed within the requisition. As such, all positions of a single requisition will always have the same rate boundaries and start and end dates. If different boundaries are needed, different requisitions must be created. |
| Resume parsing | Resume parsing can be used within the agency portal. It can also be used by sending attachments through emails. However, if the agent sending the email is associated to a portal without a general profile flow, the system will not be able to parse the attachment. This is because all email based parsing is profile based and never for a specific job. This is why there is a standard message template that informs agents associated to a portal without a profile flow that if they ever send a resume to the zonename@resumeparsing.taleo.net address, the email parsing is not supported for them. If a profile flow is active, then all standard parsing responses might be triggered. The message template is named Resume Parsing Service Unavailable to Agents. This message is triggered when the profile flow is not activated in the agency portal associated with the agent. |
| Offer module | The offer module can be used with contingent hiring, although conceptually, the interaction between the organization and the candidate is done by the agent, thus the offer module, meant to serve as a contractual agreement between the candidate and the organization, is not the natural path. While most standard fields and user-defined fields can be made available for contingent specific offers, the contingent-specific fields such as Start Date, End Date, Start Time, End Time and Staffing Agency Hourly Rate are not available in the offer module. This aligns to the original design of contingent and is the current expected behavior. |
| Agency with both Staffing and Contingent Staffing services | When both the Staffing and Contingent Staffing services are selected for a specific agency, the system will act as contingent or not based on the requisition where the candidate is submitted. But if the agents associated to such agencies are submitting new candidates as general profiles - through either a profile flow or resume parsing by email - then the system will consider those candidates as non-contingent candidates. It is recommended to have only job-specific application flows when agencies serving both contingent and non contingent are required. If an agent associated to a contingent only agency is submitting a candidate profile, then the ownership delay of the contingent definition will be applied. |
| Hiring contingent candidates | In order to hire a candidate on a contingent requisition, the candidate must be associated to an agent. All candidates submitted through the agency portal will get such association. However, candidates created manually, matched to a contingent requisition or imported might not have such agent association at first and it must be added before being able to hire the candidate on any contingent requisition. |
Requisition Fields to be Used for Contingent
| Field | Block/Form Where Available | Rules |
|---|---|---|
| Start Date | Profile | Mandatory by default, but it can be made optional. |
| Start Time | Profile | The Recruiting setting Offer Default Start Date Hour defines the value of this field. Default is 8 a.m. |
| Target End Date | Profile | Mandatory by default, but it can be made optional. |
| End Time | Profile | The Recruiting settings Offer Default Start Date Hour and Calculator Default Hourly define the value of this field. Default is 8 a.m and 8 hours per day. |
| Estimated Expenses | Contingent Terms | Represents expenses that can be added in order to calculate the total estimated cost. |
| Estimated Labor Cost | Contingent Terms | This is a read-only calculated field and it cannot be configured as an input field. The cost is a result of the number of hours per day (Calculator Default Hourly setting) and the number of days the requisition is open, based on the difference between the end date and the start date and the number of days per week, defined in the setting Calculator Default Daily, with 5 days a week being the default. Since it is a calculated field, this field cannot be configured by the system administrator. |
| Estimated Labor Cost and Expenses | Contingent Terms | This is a calculated field, and will include the Estimated Labor Cost plus the Estimated Expenses, if the Expenses Reimbursable field is checked. Since it is a calculated field, this field cannot be configured by the system administrator. |
| Expenses Reimbursable | Contingent Terms | This check box field is used to decide whether or not the expenses are included in the Estimated Labor Cost and Expenses field upon clicking the calculation option or saving the requisition. |
| Maximum Hourly Rate | Contingent Terms | Configure the field such that it is read only for managers – do not allow editing of this field by managers. Defines the maximum hourly rate allowed for the current requisition. This value should in theory come from the template if possible, since it serves to limit the requested hourly rate amount. It also controls the maximum rate an agent can ask while submitting a candidate. |
| Requested Hourly Rate | Contingent Terms | This is the requested hourly rate used to inform the agent about what should be submitted. |
Candidates Fields to be Used for Contingent
| Field | Default Field Visibility |
|---|---|
| Staffing Agency Hourly Rate | Career Section (not relevant to recruiters, for integration purpose only). |
| Sales Tax must be charged | Career Section, Taleo Recruiting. |
| Hourly Rate Paid to the Worker | Career Section (not relevant to recruiters, for integration purpose only). |
| Agency Requisition Number | Career Section (not relevant to recruiters, for integration purpose only). |
| Worker ID | Career Section (not relevant to recruiters, for integration purpose only). |
| Worker Type | Career Section, Taleo Recruiting. |
Hourly Hiring
Evergreen Hiring
Evergreen hiring is used in continuous hiring situations such as retail stores where employers want to enable candidates to apply at all times, and also want a ready supply of candidates available to move quickly when a need is identified.
Often such employers will want to implement a definite validity period and expiration for the candidate's submission, with the easy ability for the candidate to re-apply after his/her submission expires. It is not uncommon for workers in the hourly retail world to have held several different jobs within the span of a year. Employers need to ensure they are collecting all of the most recent information regarding a candidate's relevant history. This may also help to limit legal exposures in addition to confirming candidate's continued interest in employment with the employer.
A submission validity period may be enabled for any requisition, before that requisition reaches the Sourcing status. The number of days for the validity period is inherited from a default setting (initially 90 days), but may be changed for specific requisitions by users with sufficient permissions. The Validity Period and Validity Period Enabled fields may also be inherited from a requisition template. The submission validity period must be between 1 and 730 days (2 years).
The validity period starts when a candidate submits his/her completed submission. The candidate submission remains valid for the number of days defined in the requisition. For submissions created when matching or referring a candidate, the period starts on the date that the candidate was matched or referred. If a submission is incomplete and the candidate later completes it, the validity period is restarted.
The Evergreen Hiring feature basically works as follows:
For the Evergreen Hiring feature to be available, the system administrator must make the following two requisition fields available in the Recruiting application:
Validity Period Enabled
Validity Period
If desired, the security level can be set for those fields to hide them from some users. Once these fields are activated, the system administrator can add them to the requisition and/or requisition template, in the Identification block. It is necessary to have the Validity Period Enabled field in either the requisition template and/or the requisition file in order to enable submission expiration.
In the Recruiting application, when creating a requisition or requisition template, users can use the default validity period set by the system administrator or set a different validity period for the requisition or requisition template being created. The validity period must be set before the requisition is posted. The submission validity period is displayed in the requisition card (located on the left hand side of the requisition), when hovering the mouse over the Submission Expired icon.
Once the requisition is posted, candidates applying on the requisition will be informed of the expiration date of their submission on the Thank You page. Within the Recruiting Center, the submission validity period is displayed in the candidate submission card, when hovering the mouse over the Submission Expired icon.
If the candidate's submission has expired and the requisition is still posted, the Modify link is replaced with the Reapply link on the candidate's My Jobs page. When candidates re-apply for a job:
The submission's validity period and expiration date are reset.
A summary of the candidate's current information will be displayed to allow him/her to make any necessary changes.
Depending on how the zone was configured, the candidate selection workflow of the submission may be reset back to the beginning.
A tracking history is automatically added in candidate file History tab. If during the reapply process, the system forces the candidate selection workflow to be reset, a second tracking history is added in the History tab stating that.
Once candidates have applied on the requisition, the column in the Requisitions list indicating the candidate count considers if the submission validity period is enabled or not for the requisition. If the validity period is enabled, the count only includes candidate submissions that are not expired.
The system administrator also has the ability to add the following columns in the candidate lists and requisition lists. When these columns are made available in list formats, users can select them to display the desired information:
| Candidate List Columns | Description |
|---|---|
| Submission Expired | This column is represented by the Submission Expired icon. When a submission is expired, a red icon is displayed. |
| Latest Submission Date | Date when the candidate has submitted his/her submission or has reapplied. |
| Submission Expiration Date | Date when the candidate submission expires/expired. |
| Days before Submission Expiration | Displays as a countdown the number of days left before the expiration of the submission. |
| Requisition List Columns | Description |
|---|---|
| Submission Validity Period Enabled | This column is represented by the Submission Expired icon. |
| Submission Validity Period | Number of days of the validity period. |
The Hide expired submissions quick filter can be added to Candidates list to let users show or hide expired candidate submissions. Expired submissions are hidden by default. This filter is only available for requisition-specific candidate list formats.
The system administrator can also enable a setting to determine under which conditions the Candidate Selection Workflow (CSW) is reset to the initial step/status after a candidate re-applies for the same requisition (after submission expiration). The CSW will never change if the submission has reached the Offer step or if an interview has been scheduled.
New Hire Onboarding
New Hire Onboarding
Employee onboarding is the process of integrating a new employee into an organization.
Onboarding begins when a person accepts a position; it can include orientation, communication, filling out forms, getting equipment such as a laptop.
Starting a Legacy Onboarding Process
Candidate must be hired.
A user type permission grants users access to this feature.
In the Candidates list, select a candidate.
In the More Actions list, select Start Legacy Onboarding Process.
Select a process.
-
Specify if you wish to update onboarding data with current recruiting data.
Click Done.
Canceling a Legacy Onboarding Process
Candidate must be involved in an onboarding process.
A user type permission grants users access to this feature.
In the Candidates list, select a candidate.
In the More Actions list, select Cancel Legacy Onboarding Process.
Enter a comment.
Click Done.
The process is cancelled. Action is tracked under the candidate file History tab.
Updating Onboarding Data
The step/status of the candidate must be Hire/Hired.
An onboarding process must be started for the candidate.
A user type permission grants users access to this feature.
The system overwrites Candidate, Experience and Education data and updates Assignment, Position and Application data. Also, all data entered on onboarding forms prior to running this process is removed.