Things to Consider when Configuring the Advanced Electronic Offer

To extend offers electronically using Onboarding (Transitions), the Electronic Offers setting must be set to Advanced Electronic Offer, users must be granted the permission to extend offers electronically, and the candidate selection workflow must contain the RSOffer step.

The advanced E-Offer process that is launched can be configured to have various emails, forms, tasks, and participants, just like any other Onboarding (Transitions) process. Most customers will configure at least a few similar steps, as follows. Candidates can receive an email notification inviting them to access a secure career section portal to view the offer on line. Those candidates click the URL link in the email notification and are directed to the career section portal where they are required to log in. The Tasks tab is displayed and the candidates can view and print the offer details and, provided the OfferLetterAttachments variable was added to the E-Offer letter form, offer letter attachments, if any. Candidates then accept or refuse the offer and complete any mandatory fields. which may include an electronic signature.

The Advanced E-Offer Process Must Reach Completion

When configuring the advanced E-Offer process in Onboarding (Transitions), every candidate will go through this process, following any branching logic that has been configured. When designing the advanced E-Offer process, it is important to make the process reach the END and be 100% completed even if the candidate refuses the offer. After notifying the recruiter about the candidate response to the offer, the process should have a branch for when the candidate accepts the offer and another branch for when the candidate refuses the offer. When the offer is refused, the process should go directly to the final routing step. This is required if you want to be able to issue a new offer after a refusal.

Using the Offer Expiration Date

Some organizations use expiration dates on their offers in the Recruiting Center to indicate the latest date by which a candidate can respond to an offer. By default, the Onboarding (Transitions) advanced E-Offer process does not take the expiration date into consideration when updating the candidate's status. Instead, the advanced E-Offer "Send E-Offer response" task verifies that the status is still Offer-Extended and then it updates it to Offer-Accepted or Offer-Refused. So. if the offer expiration date is important to your organization, the advanced E-Offer process must be configured to handle this specifically.

One suggestion is to create a condition immediately after the candidates submit the form containing their response to the offer. This condition checks to see whether the expiration date is in the past.

• If the expiration date is not in the past, the process should proceed as expected: triggering the task that updates the status and then notifying the recruiter of the offer's new status.

• If the expiration date is in the past, the process should be configured to take a different action: perhaps to tell the candidates that they are too late, or to tell the recruiter that a late response has been received, or to do whatever the company's business requirements dictate.

Using the {Offer_Para.StatusDescription} Variable

When creating the message informing recruiters of the candidate response to the offer, the variable {Offer_Para.StatusDescription} displays the current status of the offer, which presumably is the same as the response that the candidate provided on the E-Offer form. In cases where something in the process was not properly configured, or the recruiter manually entered a different response for the offer before the candidate submitted the form, or Taleo Connect imported a different response before the candidate submitted the form, there is the possibility that the response from the form and the actual status will be out of sync.

Note: To account for such situations, it is important that administrators use the {Offer_Para.CandidateOfferResponse} and {Offer_Para.StatusDescription} variables differently. Administrators should include the {Offer_Para.CandidateOfferResponse} variable only on onboarding forms whose purpose is to capture candidates' response. Only the {Offer_Para.StatusDescription} variable (not the {Offer_Para.CandidateOfferResponse} variable) should be included on forms that follow later in a process because this variable displays the true current status of the offer regardless of whether the candidate's recent response was successfully saved in the system.

Validating E-Signatures

Several methods are available to validate the E-Signatures provided by candidates, and a subset of these methods are available for other participants' E-Signatures.

These signatures are validated, which means that the value entered by the assignee must match the information already known about that assignee. If these values do not match, then the form on which th E-Signature field is placed cannot be successfully submitted and the task cannot be completed.

It is recommended to configure the E-Signature field(s) as required fields on the Onboarding (Transitions) form, to ensure that it cannot be submitted without confirming the assignee's identity.

Understanding the "Send E-Offer response" Task

The task whose action is "Send E-Offer response" is used to communicate the candidate response back into the Recruiting Center candidate selection workflow. This task must be placed after the candidate response is captured, and preferably before the recruiters/participants are notified. The task will update the Offer status automatically in the candidate selection workflow to Offer - Accepted or Offer - Refused but the task requires an assignee. It is recommended to use a "dummy" assignee (it is best not to use the candidate or new hire). The task will quickly disappear because it gets completed as soon as it is triggered in the process.

Adjusting the Advanced E-Offer Process

Sometimes, changes in an organization business requirements cause the need to make adjustments to the advanced E-Offer process definition. A new process must be defined, tested, and then enabled to replace the prior process that was in use. However, there can only be one advanced E-Offer process in use at a time for each zone.

You can create a new advanced E-Offer process (usually by duplicating the old active process) and make the necessary changes to it. Give this process a temporary name such as “Do Not Use – E-Offer Test Process”. Then, give this process a process type such as Pre-Hire (but not E-Offer), and then enable it. Now, test that candidates can be launched into this process to ensure that no configuration errors were made. These candidates can be started by any Recruiting Center user who has the permission to start Pre-Hire processes for a new resource. As soon as you are satisfied that this new process is working smoothly, you can change its process type to E-Offer and then disable the old advanced E-Offer process.