5Fields and Selections
Fields and Selections
Data Sharing Between Taleo Recruiting and Taleo Onboarding (Transitions)
Most fields are shared by Taleo Recruiting and Taleo Onboarding (Transitions).
Candidate-related fields, whether standard or user-defined, are shared by Taleo Recruiting and Taleo Onboarding (Transitions). A change to candidate information on the Taleo Recruiting side or on the Taleo Onboarding (Transitions) side is immediately and automatically reflected in the other product. This includes cases where:
Candidates update candidate-related fields in their job submissions in career sections.
Candidates update candidate-related fields while performing tasks on the career section Tasks tab.
Recruiting Center users make changes to candidate or job submission fields.
Onboarding (Transitions) Center users such as hiring managers update candidate-related fields while executing form tasks.
Taleo Connect updates candidate-related fields.
A second group consists of standard and user-defined fields of type Offer, Requisition and Department. If these fields are edited by candidates (e.g. during a job submission), by Taleo Recruiting users or via Taleo Connect, the new value is displayed immediately in Taleo Recruiting, on the candidate's Tasks tab in career sections, and in Taleo Onboarding (Transitions). Fields in this group cannot be edited in Taleo Onboarding (Transitions) however.
A third group of fields is specific to Taleo Onboarding (Transitions), therefore, not shared with Taleo Recruiting. If the fields are part of task, they can be updated by candidates on the Tasks tab. They can be updated by Onboarding (Transitions) Center users or via Taleo Connect. They are not displayed and cannot be updated through job submissions or through the Recruiting Center. Fields specific to Taleo Onboarding (Transitions) are:
Information about Onboarding (Transitions) processes and tasks, their statuses and completions.
Onboarding (Transitions) process standard fields. They can be displayed and updated on any assigned onboarding form for any Onboarding (Transitions) assignee but they cannot be used in Taleo Recruiting, either by candidates or by Recruiting Center users.
Onboarding (Transitions) process user-defined fields, which are created in Onboarding (Transitions) Administration. These fields have no values when a process is first started. They can be displayed and updated on any assigned onboarding form for any Onboarding (Transitions) assignee but they cannot be used in Taleo Recruiting, neither by candidates nor by Recruiting Center users.
Personal information standard and user-defined fields.
Submission, Offer, Requisition and Department fields, which are displayed in Taleo Recruiting and Taleo Onboarding (Transitions) but are editable in Taleo Recuiting only.
External service result fields created from Oracle Validated Integration (OVI) partners in Taleo Onboarding (Transitions).
Fields captured for E-Signatures on onboarding forms.
Direct deposit information.
Address fields that have a "table" format and multiple rows, for previous or secondary addresses (AddressBookHistory is an example).
I-9 fields for storing locally-captured I-9 information (not via an external service provider) such as citizenship, names and dates for documents from lists.
Editable vs Read-only Fields
All of the following Recruiting standard fields and user-defined fields are available in Onboarding (Transitions) automatically. The Onboarding (Transitions) administrator can add them to forms, message templates, documents and content pages. Recruiting fields are available under Configuration > [Recruiting] Administration > Fields.
Candidate standard fields and user-defined fields: These fields are created in Recruiting Administration. They can be displayed and updated in the Recruiting Center and the Onboarding (Transitions) Center. They can also be updated by candidates/new hires in the Career Section. The value of a candidate UDF is specific to the candidate and is consistent for every job for which the candidate submits an application. For example, U.S state driving license would be a good choice for a candidate UDF, a value that is specific to the candidate and independent of job submissions and processes. The Onboarding (Transitions) administrator can add candidate standard fields and UDFs to forms and configure the fields so they can be updated in the Onboarding (Transitions) Center as well as by candidates/new hires in the Career Section.
Submission standard fields and user-defined fields: These fields are created in Recruiting Administration. They can be displayed and updated in the Onboarding (Transitions) Center but not in the Recruiting Center. The value of this type of UDF is specific to each of the candidate's job submissions. For example, equipment preferences would be a good choice for a job submission UDF because candidates/managers can provide a different value depending on the requisition.
Offer standard fields and user-defined fields: These fields can only be read-only when displayed on onboarding forms because there are proper ways to update these fields within the Recruiting product. It would not be desirable to make changes to an onboarding form that bypassed any Recruiting approval procedures that have been put in place for these types of information.
Requisition standard fields and user-defined fields: These fields can only be read-only when displayed on onboarding forms because there are proper ways to update these fields within the Recruiting product. It would not be desirable to make changes to an onboarding form that bypassed any Recruiting approval procedures that have been put in place for these types of information.
Department standard fields and user-defined fields: These fields can only be read-only when displayed on onboarding forms because there are proper ways to update these fields within the Recruiting product. It would not be desirable to make changes to an onboarding form that bypassed any Recruiting approval procedures that have been put in place for these types of information.
Taleo Recruiting standard and user-defined fields often have properties (such as Availability, Content Required and Security Level) and Organization, Job Field and Location (OLF) criteria that can be configured. Be aware that the effect of a field's properties and OLF does not extend to Taleo Onboarding (Transitions). Suppose, for example, you created a user-defined field in Recruiting Administration. The field would be available automatically to the Onboarding (Transitions) administrator. If you later selected or deselected the property that makes the field available in Taleo Recruiting, these actions have no effect on the field's availability in Taleo Onboarding (Transitions). The Taleo Onboarding (Transitions) administrator would still be able to add the field to forms and the field would be displayed to the assignees of the forms. To summarize, a standard or user-defined field in Recruiting Administration is available and can be used in Taleo Onboarding (Transitions) independent of the field's property and OLF configuration.
Onboarding (Transitions) user-defined fields are created under Configuration > [Onboarding (Transitions)] Administration > User-defined Fields.
Standard Fields and User-defined Fields
Onboarding (Transitions) uses both standard fields supplied by the system as well as user-defined fields (UDFs) created by your organization to capture any additional information that is needed about a new hire, candidate or employee.
Important Information
There are two general categories of fields available for input on forms or for use in message templates, PDF documents, content pages, conditions, reports and Taleo Connect imports and exports:
Standard fields Supplied with the system, these fields include standardized information on a candidate, an offer, or the current task such as candidate's name, the offer's proposed salary, or the current task's due date.
User-defined fields Onboarding (Transitions) administrators often create UDFs when there are not appropriate standard fields to capture the information that their business requires.
Both standard fields and user-defined fields display current read-only information on PDF documents, content pages and message templates. If the Onboarding (Transitions) administrator configures the fields such that they are editable on forms, people can replace the current information via the forms with more recent data.
Onboarding (Transitions) Process user-defined fields: Onboarding (Transitions) Process user-defined fields are specific to the process. These fields are created in Onboarding (Transitions) Administration. They can be displayed and updated on any assigned onboarding form for any Onboarding (Transitions) assignee but cannot be used in Recruiting at all, neither by candidates nor by Recruiting Center users. Take the case of a "Do we have signatures yet?" user-defined field. A "Yes" value would trigger one series of Onboarding (Transitions) steps while a "No" value would trigger a different series of steps. Each time a process is started or re-started, the user-type field would need to be completed regardless of the candidate or the job submission.
Personal Information user-defined fields: These fields are created in Onboarding (Transitions) Administration. They can be displayed and updated in the Onboarding (Transitions) Center but not in the Recruiting Center. These fields are persistent for the person in all processes. Each time a new Onboarding (Transitions) process of any type gets launched for the person, the values in these fields will be displayed again and can be updated. This is very similar to the UDFs created by the Recruiting administrator in the Candidate Personal Information category. Additional UDFs can be created in Onboarding (Transitions) Administration to augment the list of Recruiting Candidate UDFs. When an OVI service is installed, this usually introduces some vendor-specific UDFs into a zone. These UDFs are defined by the OVI vendor for use with its service and they appear in the Onboarding (Transitions) Personal Information UDF category. These fields are usually filled for each candidate/new hire when the service is invoked during an Onboarding (Transitions) process. These fields can be used in all the same places as all other UDFs to display the results of the OVI service.
There is no limit in the number of Onboarding (Transitions) UDFs that you can create. Limiting the number to 250 is a best practice because you can assign a Reporting ID to up to 250 UDFs per entity type (Requisition, Candidate, Offer, Department, Work Experience, Education, Submission), making those UDFs available to be included in reports created with OBI Reporting.
In Recruiting Administration, in the Custom Report Universe configuration page, the limit of UDFs is 250. (Path: Recruiting Administration > Custom Report Universe)
In Onboarding (Transitions) Administration, in the User-defined Reporting configuration page, the limit of UDFs is 250. (Path: Onboarding (Transitions) Administration > User-defined Reporting)
The 250 UDF limit is available to existing and new customers but there is a private setting that controls the number of UDFs to report on.
To use more UDFs in reports, system administrators need to configure Recruiting and Onboarding (Transitions).
The 100 UDF limit remains in Legacy Onboarding.
In the Custom Report Universe configuration page, if one of the UDFs for an entity type (Requisition, Department,Offer, Candidate, Experience, Education, Submission) has its Reporting ID set to 250, the following error message will be displayed when trying to make another UDF available in reporting: "The maximum number of user-defined fields has been reached for the Custom Report Universe". This message will be displayed even if other Reporting IDs are still available to be assigned to a UDF. This is a known issue. As a workaround, we recommend not assigning the Reporting ID number 250 until all other Reporting IDs have been assigned to other UDFs.
Types of User-defined FieldsWhen creating user-defined fields in Onboarding (Transitions) Administration, the following types can be created:
| User-defined Field Type | Description |
|---|---|
| Boolean | User-defined field of type True/False. In a user-defined form, it is represented with a check box. With regard to reporting, this type of user-defined field will not be supported. Instead, customers can create user-defined fields with two selections: "True" and "False". |
| Date | User-defined field containing a date. |
| Date and Time Zone | User-defined field containing a date and a time. With regard to reporting, this type of user-defined field will not be supported. |
| Multilingual Text | User-defined field containing more than one value in different languages. |
| Numerical | User-defined field containing whole numbers. Numerical fields can only accept digits, not commas, decimal points nor leading zeros. If a field is intended to capture numbers that will contain this type of punctuation, then the Onboarding (Transitions) administrator who creates the form should create and use a UDF of type Text instead. |
| Text | User-defined field containing numbers and letters. |
Multi-row Fields
Some UDFs are multi-row fields. They are used within a form to gather or display information that requires several different rows. (Whether this type of field will be supported for reporting purposes has not been determined.) For details, see Multi-row Fields in the "User-defined Form" section.
Creating an Onboarding (Transitions) User-defined Field
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
The new field appears in the User-defined Fields list. It is available when creating user-defined forms, message templates, and documents. It is also available in Taleo Connect exports.
User-defined Selections
A user-defined selection is a list of possible choices with which a user-defined field can be filled.
When a predefined list of choices (instead of free-form text answers to be entered by an assignee) is needed, the Onboarding (Transitions) administrator can create these choices with user-defined selections. These user-defined selections are then used by a user-defined field that the Onboarding (Transitions) administrator creates. User-defined selections created in Recruiting Administration can be used in the Recruiting Center and Onboarding (Transitions) Center. However, user-defined selections created in Onboarding (Transitions) Administration can only be used in the Onboarding (Transitions) Center.
When creating a user-defined selection, you can specify the type of selection users will be able to make:
No Selection: No selection is provided. For example, a text field where the user must type in a value.
Single Selection: A selection of answers is provided, but the user can only select one answer.
Multiple Selection: A selection of answers is provided and the user can select multiple answers.
User-defined selection elements (choices) can be enabled and disabled after initial activation. After user-defined selection elements are in active use, they can be disabled for future use if necessary. This enables an organization to change its list of possible responses over time, as older responses become obsolete while responses on older completed forms are preserved.
Whenever an end-user is asked to make a choice among the elements in a user-defined selection, they are always presented with the currently active elements. For instance, if user-defined elements A, B, and C are currently active, then a task assignee who fills out a form is presented with choices A, B, and C. Later, if element A is disabled and element D is enabled, a subsequent task assignee who fills out the same form is presented with choices B, C, and D. However, later in that first assignee's process, they were given another form and another opportunity to revise that answer, they would see the currently-available choices B, C, D. They would no longer be permitted to actively choose the user-defined element A after its deactivation. The first assignee may get a later opportunity to fill in a form that contains the same user-defined field. At that time, they will still see the original value A that they chose. But if they wish to revise that answer, they would see the currently available choices B, C, D.
Creating an Onboarding (Transitions) User-defined Selection
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
-
You first need to create the selection:
-
You then create the elements (choices) provided for the selection:
-
Click Create next to Elements.
-
Enter a code and a name.
-
Click Save.
-
Create as many elements as required for the selection.
-
Assign Active status to the elements.
-
-
Enable the selection.
-
You then add the user-defined selection to a user-defined field.
User-defined Fields and Selections - Other Configuration Tasks
Selecting User-defined Fields for Reports
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
-
Click Transitions Process.
-
In the list of available items, select the desired fields and click Add.
-
Use the up and down arrows to indicate which UDF will be reportable in which slot in the reporting tool.
-
Click Save.
-
Click Yes to confirm.
That data is available for reporting.
Deleting a User-defined Field
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
-
Click Transitions Process or Personal Information.
-
Next to the user-defined field, click Delete.
-
In the message box, click Yes.
The field can no longer be used in user-defined forms, message templates, documents, conditions, or in Taleo Connect exports.
Deleting a User-defined Selection
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
-
Click Delete next to the user-defined selection.
-
Click Yes in the message box.
The selection can no longer be used in user-defined forms, message templates, documents, conditions, or in Taleo Connect exports.
Deleting an Element in a User-defined Selection
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
-
Click a user-defined selection.
-
Click Delete next to an element.
-
Click Yes in the message box.
Disabling an Element in a User-defined Selection
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
The element must be Active.
-
Click a user-defined selection.
-
Click Deactivate next to an element.
-
Click Yes in the message box.
Disabling a User-defined Selection
The Manage user-defined fields, e-signatures, and user-defined reporting permission is required.
The user-defined selection must be enabled.
-
Click a user-defined selection.
-
Click Deactivate.
Electronic Signatures
Electronic Signature
Electronic signatures enable an organization to validate the identity of a new hire, manager, or other task assignee when they are submitting a specific set of information on a form.
The Onboarding (Transitions) administrator can configure and use an electronic signature in forms, message templates, documents, content pages. For example, candidates and employees may have to read and complete specified forms and may be asked to provide specific information confirming their identity. The information they provide is checked by the system before the form can be submitted. For instance, the system can validate if the data entered matches the last name, initials and Taleo password.
The Electronic Signature feature is flexible and extensive. Onboarding (Transitions) provides 50 E-Signature fields that can be used by the Onboarding (Transitions) administrator to meet the organization's business needs. There are also three E-Signature fields intended for use with the I-9 form, and one E-Signature field intended for use with electronic offers. The Onboarding (Transitions) administrator configures an electronic signature field by naming it and selecting the value to validate against. The newly configured name will not appear in the user-defined form builder, PDF document variables, or text documents but is available for reporting. Forms and documents are built using the predefined E-Signatures.
Any of the 53 "ESignature" variables in the Available Variables list can be used in multiple processes. A customer could configure a pre-hire process, a new hire process, an e-offer process and an offboarding process such that a candidate would provide the same E-Signature (e.g. {ESignature.ESignature45Fullname} ) on four separate occasions as he or she progressed from one process to the next and each e-signature would be treated and processed separately from the others.
There a several methods of validation that can be used for an E-Signature. When determining which validation method to use, the Onboarding (Transitions) administrator must consider their business process. If data in any of these fields has not been previously captured in the system for the assignee, it will then be impossible for the assignee to successfully submit the form (the system cannot compare the information that is typed in the E-Signature). For example, if the Taleo password is a mandatory field for all users in an organization, this validation method would be a good choice. On the other hand, if an organization does not collect the date of birth for all candidates, this would be a poor choice to use for an E-Signature.
| Use this E-Signature validation method | If the assignees are in this group of people | Notes |
|---|---|---|
| Birth date | New hires only | Must be typed in mm/dd/yyyy format only, with the new hire typing each number and slash directly into the field to be accepted as a valid E-Signature. |
| All | Can match any one of three possible email addresses that can potentially exist in Onboarding (Transitions):
|
|
| First name | All | |
| Initials | All | If the assignee has a middle name, then the first initial of the first, middle, and last name must be typed into the field without periods or spaces between them. If the assignee does not have a middle name, then the first initial of the first and last name must be typed into the field. |
| Last name | All | |
| SSN last 4 digits | New hires only | Before choosing this validation method, the Onboarding (Transitions) administrator needs to be confident that the Social Security Number/Social Insurance Number value was properly entered in the system. The Onboarding (Transitions) administrator should make sure that the SSN/SIN field is filled with digits only, no extraneous dashes nor spaces. If gathering the SSN/SIN in an onboarding form, this can be done on a form that uses an input mask to ensure that they only save 9 digits. |
| Taleo password | All | |
| User secret identifier | New hires only | Before choosing this validation method, the Onboarding (Transitions) administrator must ensure that there is data saved for this field in the database. The secret identifier entered by the assignee must match the data saved in the database. If the system administrator forgot to capture the data in the first place, then this E-Signature method will always fail. |
| Zip/postal code | New hires only | Before choosing this validation method, the Onboarding (Transitions) administrator must ensure that there is data saved for this field in the database. The zip/postal code entered by the assignee must match the data saved in the database. |
From Recruiting and the Career Section.
It can be filled in manually on a prior onboarding form by the new hire or other user on their behalf.
It can be imported using Taleo Connect after it has been generated for new hires in an external system.
Configuring an Electronic Signature
The Manage user-defined forms to display and collect data permission is required.
-
Click a precoded electronic signature from the User-Defined Electronic Signature Management list.
-
Rename the signature with a meaningful name.
-
Select the type of signature.
-
Click Save.
The electronic signature can be successfully used in a form.
Electronic Signature on a Form
The Onboarding (Transitions) administrator can configure and insert electronic signature fields into a form.
Each of the 50 available electronic signatures should only be used on one form in a single process. It is important not to reuse an electronic signature. Instead, the Onboarding (Transitions) administrator must define a specific electronic signature which is intended to be used on a specific form. If one single electronic signature field is placed in two forms, then it can appear to the users as if the second form has already been signed or the second form's electronic signature can overwrite the information about who signed the first form and when. For example, if using Signature1 in a I-9 form, it cannot be used in the Sexual Harassment form in the same process. Signature2 would need to be selected and configured for use on the Sexual Harassment form.
The E-Signature is a set of four fields. There is one main field (Esignature[Number]) that must be configured onto forms for capturing the signer's electronic signature data, and the other three fields (Esignature[Number]Date, Esignature[Number]IPAddress, Esignature[Number]FullName) are intended to display back information about the successful capture of that signature. The main field must be used as editable and is only meaningful when configured onto the form where the signature will be validated and submitted. The other three fields for viewing the information about the signature can only be read-only and these are useful on PDFs, reports or exports, and when viewing past-submitted forms in read-only as well. These fields help legal departments consider how to best meet their regulatory and compliance needs. They can be inserted as a variable into PDFs, message templates, content pages.
The following table describes the four fields.
| Field | Completed by | Notes |
|---|---|---|
| Esignature[Number] | Assignee | Typed information that will be compared against the specified E-Signature value. Configure this field to appear on only one form and consider making this field mandatory. Do not configure this field onto other forms, PDFs, or message templates. It is not possible to display back the data that was provided by the assignee for validation. |
| Esignature[Number]Date | Automatically by Onboarding (Transitions) | Timestamp indicating when the form containing the E-Signature was submitted. When the corresponding field has been captured and submitted, this field becomes read-only. |
| Esignature[Number]IPAddress | Automatically by Onboarding (Transitions) | The IP Address captured is from either the submitting computer or that computer network's firewall. When the corresponding field has been captured and submitted, this field becomes read-only. |
| Esignature[Number]FullName | Automatically by Onboarding (Transitions) | This field is filled automatically once the Esignature[Number] field is captured. It will contain the first and last name of the assignee. The purpose of this field is to display the assignee's full name because the Esignature[Number] field is not visible once it has been submitted. In other words, if the Onboarding (Transitions) administrator designs a form that only contains the Esignature[Number] field, once the form is submitted and has been viewed as a read-only completed form, the name of the assignee will not be displayed. On the other hand, if the form was designed to include the Esignature[Number] field for capturing the electronic signature AND the Esignature[Number]FullName, then after the form is successfully submitted, a person opening the completed read-only form will see the meaningful information about the assignee's first and last name. |
After submitting the form with a correct E-Signature filled in, a History event gets logged at the bottom of the step, showing who successfully provided the E-Signature and the timestamp of submission. Other events are also logged, such as failed E-Signature attempts due to wrong data provided and failed attempts due to missing the necessary E-Signature information from Onboarding (Transitions) to validate.
Configuring an Electronic Signature Field to Capture Data on a Form
The Manage user-defined forms to display and collect data permission is required.
The ESignature field can be used in a process.
Electronic Signature on a PDF
The Onboarding (Transitions) administrator can configure and insert electronic signature fields into a PDF document to display information about signatures that were successfully captured on onboarding forms.
PDF documents can be created by the Onboarding (Transitions) administrator to display any type of information that has been gathered in the Taleo system, including displaying specific information about electronic signatures that have been successfully captured on forms that precede the PDF in each candidate/new hire's Onboarding (Transitions) process. The Esignature[Number]FullName, Esignature[Number]Date and Esignature[Number]IPAddress fields are available for inclusion in the PDF. Once entered on the PDF, custom formatting can be applied to these fields using Adobe Professional. For example, the Esignature[Number]FullName field can be displayed in dark blue italics to simulate an ink signature while the rest of the PDF's text can be black.
A PDF with an E-Signature can be displayed in the Onboarding (Transitions) Center and in the career section within any Onboarding (Transitions) Task. If the user's E-Signature was valid when submitted, then the Esignature[Number]FullName field will display the first name and last name of the signer, not the actual value they entered. If added to the form, the Esignature[Number]Date field will display the timestamp of successful submission of the form. If the submission attempt was not successful, then any user who can view this PDF will see both fields as empty. An assignee can make several unsuccessful attempts to submit a form with invalid data in the Esignature field. These unsuccessful attempts are recorded and the form does not get completed. If after one or more unsuccessful attempts the PDF (or any other form or message template that uses these fields) is viewed, the fields will be null.
Adding an Electronic Signature in a PDF
Adobe Acrobat Professional is required to insert electronic signature fields into PDF documents. Note that this procedure may differ according to the version of Adobe Acrobat Professional being used. The procedure below is described using version 7.0.
Electronic signature fields will appear on the PDF after they have been associated with any candidate/new hire as long as a successful electronic signature has been captured for that set of fields during the current process. The PDF document containing an electronic signature can be used in the Onboarding (Transitions) Center and in the Candidate Portal within any Onboarding (Transitions) Task.
Date and Time Setting for Electronic Signatures
The ESignature.ESignature[number]Date field captures the date and time when an E-Signature was successfully captured.
The ESignature.ESignature[number]Date field is a timestamp of when a document was signed by a new hire or assignee using an electronic signature field. The ESignature.ESignature[number]Date field is available as a variable that can be included on forms and message templates, in PDF documents, content pages, conditions, reports and Taleo Connect exports. It can be set to be displayed in two different ways, either by date alone or by date and time. The date will always be formatted using a default short date style. The time will be displayed using the Greenwich Mean Time (GMT) time zone. If your organization operates in a single or a few time zones, then the date of an E-Signature would probably be sufficient by your organization's legal department or other compliance considerations. But if your organization operates globally, it might be more important to know exactly when each E-Signature was captured, according to one centralized system. This setting will apply to all electronic signature fields, including existing fields on forms that have already been signed.
The default value is Date and will apply to all ESignature.ESignature[number]Date fields.
Configuration
| Type Permission | |
|---|---|
| Name | Location |
| eSignature Timestamp Display Property |
|