Overview
iForms are electronic forms used to collect data in iCIMS Applicant Tracking (ATS) and iCIMS Onboarding. These forms can be configured to mimic existing paper forms that you may already use at your organization. iForms reduce manual data entry and streamline searching and reporting on submitted information. All iForms are stored within the system and are typically associated with Recruiting Workflow or Person profiles. Less frequently, iForms may be associated with Job profiles, Onboarding Workflow profiles, and other profile types within the system. iForms enable users to see all completed forms associated with a particular profile within one tab of that profile and in a standardized format.
iForms can also be used on iCIMS Applicant Tracking (ATS) career sites and new hire portals to collect required information from candidates, new hires, and employees. Common documents that clients convert to iForms include employment applications, offer letters, tax withholding forms, policy acknowledgment forms, and direct deposit forms. Users can request that candidates and employees complete iForms by either emailing the URL for the iForm to the contact or by asking the contact to log in to the career site or new hire portal to complete the form.
This article will cover the following topics:
iForm Types
There are three main iForm types available: Standard, Custom, and Acknowledgement.
Standard
Standard iForms are forms that are available at no additional cost for all customers of ATS and Onboarding. These include government tax forms, as well as forms for background checks and voluntary self-identification, among many other options. Whenever a standard iForm is updated (e.g., if a new revision of a government form is made available), those updates will automatically be made to the associated iForm in your organization's instance of the iCIMS Talent Cloud.
Periodically, iCIMS adds new forms to the standard library. In order for a new iForm to be considered for inclusion in the Standard iForm Library, all of the following conditions must be met:
- It is used within an organization's talent acquisition workflow
- It is standardized by a government body and required on a federal level, state level, or by a large municipality
- It does not include the collection of personal health information
For a full list of standard iForms, see the iCIMS Standard iForms Library.
Custom
Custom iForms are forms that are created completely from scratch for a customer's use. The customer decides exactly what information and which fields they would like to use within the form. Common examples of custom iForms include offer letters and custom employment applications.
Acknowledgement
Acknowledgement iForms are a type of custom form that contain only informational text and a checkbox at the bottom. No other fields can be added to this type of iForm. Common examples of acknowledgment iForms include company handbooks and company policy forms.
User admins can create and manage acknowledgement iForms directly within iCIMS ATS. For more information, review the
Creating and Managing Acknowledgement iForms article.
Answer Types
Public
An iForm that uses public answers is associated with one profile where its answers can be seen or edited by any individual with the necessary permissions. Any subsequent edits or updates that are made to an iForm with public answers will overwrite the previous version upon saving. Public answers can be reported on in many types of searches, such as Person or Recruiting Workflow searches.
For example, a standard iForm that uses public answers is the Direct Deposit Enrollment form. This form has two sections: one that the new employee fills out and signs, and another that the payroll manager signs. The form can be viewed on the iForms Tab of the associated Person profile. If any of the information entered on the form becomes inaccurate at a later date, any system user with appropriate permissions can then edit the form and update the information, overwriting the previous information upon saving.
Private
An iForm that uses private answers is associated with one profile and allows multiple individuals to each complete a unique set of answers within their own copy of the form. Their answers do not affect or overwrite another individual's responses. Private answers can only be reported on using iForm or iForm Response searches.
For example, a standard iForm that uses private answers is the Interview Evaluation Form. If Jim Schmidt is interviewing with five different people at your organization for a Proposal Writer position, each one of those five people can fill out an interview evaluation form without overwriting each other's answers. Once the form has been completed by each interviewer, a recruiter can go into the iForms Tab on Jim Schmidt's Recruiting Workflow Profile for the Proposal Writer position and view a distinct interview evaluation form from each interviewer using the Completed As dropdown.
Profile Associations
Person
Most commonly, iForms are associated with the Person profile. Person iForms are used to capture non-job-specific information about an individual. These iForms can be viewed and accessed on the iForms Tab of the Person profile.
Note: Pre-populated fields on a Person iForm can pull information from the associated Person profile only and cannot pull information from any jobs or other profiles that the person may be associated with inside the system.
Common examples of a Person iForm include:
- Employment Applications
- Background or Reference Checks
Note: Customers who have purchased Onboarding have access to an additional set of standard Person iForms that are used specifically when onboarding a new hire (e.g. Direct Deposit, Federal I-9 and W-4, State Tax forms, etc.).
Recruiting Workflow
An iForm associated with the Recruiting Workflow profile is associated with one specific person and one specific job. Recruiting Workflow iForms are used to capture job-specific information about an individual. These iForms can be viewed and accessed on the iForms Tab of the Recruiting Workflow profile.
Notes:
- Since iForms with this type of association are unique per person per job, it is possible for one candidate to have filled out multiple copies of the same form if the candidate has applied to multiple jobs at an organization.
- Pre-populated fields on a Recruiting Workflow iForm can pull information from the associated Recruiting Workflow profile, Person profile, and Job profile.
Common examples of a Recruiting Workflow iForm include:
- Offer Letters
- Interview Evaluation Forms
Job
Job iForms are typically used to capture information relating to the recruiting process for the associated job. These iForms are not related to candidates that have applied to the associated job. Job iForms can be viewed on the iForms (Job) tab on the Job profile.
Notes:
- The iForms (Job) tab on the Job profile is hidden by default for customers who do not use Job iForms. This tab is unhidden when a customer adds or purchases a Job iForm for use.
- Pre-populated fields on a Job iForm can pull information from the associated Job profile only and cannot pull information from any person or other profiles that the job may be associated with inside the system.
Common examples of a Job iForm include:
- Intake Meeting/Notes: for use when an organization has specific processes for planning a recruitment strategy that involves business partners or a hiring manager and wants to make that information readily available on the Job profile.
- Hiring Manager Recruiting Satisfaction Survey: A standard form typically completed by the hiring manager of a job providing feedback about the recruiting process for the given job after the position has been filled.
Onboarding Workflow
iForms can also be associated with the Onboarding Workflow profile. Onboarding Workflow iForms are used to capture job-specific new hire information.
Notes:
- Pre-populated fields on an Onboarding Workflow iForm can pull information from the associated Person profile, Job profile, and New Hire Category profile.
- Onboarding Workflow iForms are often assigned as tasks to be completed by the new hire when they log in to the new hire portal. Onboarding Tasks can be assigned to new hires using Suggested Tasks on a New Hire Category profile (see Creating a New Hire Category Profile) or as individual tasks on the Onboard Status tab of the new hire's Person Profile (see Onboarding a New Hire).
- Organizations who practice seasonal hiring (i.e. where a new hire may be hired multiple times for the same job) can use Onboarding Workflow iForms to allow the new hire to fill out a new copy of a form for each time they are hired. In order to do this, the form must be associated with a different New Hire Category profile each time it is sent to the new hire to be filled out.
Common examples of an Onboarding Workflow iForm include:
- Voluntary Self-Identification of Disability (post-offer)
- Voluntary Self-Identification of Veteran Status (post-offer)
- Job-specific New Hire Checklists
iForms associated with Location profiles, Talent Pool profiles, and other profile types are also available. If you think you may be interested in creating an iForm using an association type not described in this article, contact your iCIMS account manager for more information.
iForm Configuration Options
Documents provided to iCIMS by Subscriber for iForm development must be in Microsoft Word format. The textual content of the Word file needs to be editable. For clarity, the iCIMS iForm development team needs to be able to copy and paste the content. The text cannot be part of an image. The file also needs to be in an unprotected format as it needs to be fully editable and accessible when iForm development opens it.
Additional professional services charges will apply if forms are provided to iCIMS in other formats. Such additional professional services must be authorized by Subscriber, in writing, via a new Order Form prior to the commencement of such professional services. No data feed services are included by default; all feeds must be outlined as additional professional services.
Sections
iForm sections are used when multiple individuals need to complete different segments of the same form. Unlike on a physical form, "sections" of an iForm do not refer to the spatial organization of information on the form. Instead, sections of an iForm are used to grant users permission to only fill out certain fields on the form.
For example, sections can be used in a custom Offer Letter iForm. When the recruiter completes the offer letter form in the system, they have permission to edit only the fields that contain offer detail information. The recruiter, however, does not have permission to access the candidate signature field, since that field is not within their section. Then, once the form is sent to the candidate, the candidate has permission to sign the offer letter but is unable to edit the other fields containing offer details, as those fields are not within the candidate section.
Field Dependencies
Field Dependencies allow a form to display or hide any number of fields and/or text depending upon the response given to another question on the form. The question that determines if certain segments of a form should be displayed or kept hidden must have set answers available for selection, formatted as a single-select dropdown or radio group.
For example, a field dependency can be used in an employment application for the question, "Do you have any relatives employed by this organization?". This question is typically followed up with "If yes, give name(s) and title(s)." A field dependency would enable the form to only display that follow-up request for more information if the candidate answers "Yes" to the initial question. If a candidate answers "No" to the first question, the follow-up question would not display.
Field Groups
Field groups, also referred to as collection fields, are used when an entry on an iForm involves a set of multiple fields. For example, a common field group used in iForms is Work Experience, which includes separate fields for Employer Name, Job Title, and Salary, among other employment information. Each employment detail is its own separate field, but the fields are all organized together as a set within the Work Experience field group.
Field groups are useful in situations where the individual filling out the form may need to provide multiple sets of responses for one entry. In the example of the Work Experience field group, a candidate filling out a Standard Application iForm is able to fill out multiple sets of fields for their past work experiences, where each set has its own unique Employer Name, Job Title, etc. Field groups keep forms concise by allowing the individual completing the form to only add as many sets of fields as they need to house their own information.
On an iForm, by default, each field group is able to accommodate up to five sets of information (e.g. a candidate would be able to enter five different past work experiences), but this maximum can be increased as needed. The number of fields that can be included within a field group is unlimited.
Sync with Profile Field
iForm fields can be set to "Sync with Profile Field" to ensure that information in a profile and within an iForm are aligned. When an iForm is synced with a profile, any time the iForm is updated, the corresponding profile field(s) are updated and vice versa. In order for a field to use this option, it may not be hidden on the associated profile. For more information about Sync with Profile, submit a case to iCIMS Technical Support.
Notes:
- Sync with Profile Field cannot be added to iForms that are already in use. Similarly, it cannot be removed from an iForm that is already in use.
- Certain field types are not eligible for syncing with iForm fields. For more information, submit a case to iCIMS Technical Support.
Prepopulation
Prepopulation enables fields within an iForm to be automatically filled out with custom text or information pulled from a related profile within Applicant Tracking or Onboarding. Prepopulating fields within an iForm increases efficiency by utilizing information already stored in the system. iForm fields can be prepopulated with default responses that are same for all individuals who complete the form, such as the fields within the employer section of state tax forms. Alternatively, each iForm field can be set to prepopulate information from a specified profile field within the system.
For example, the Standard Employment Application iForm contains contact information fields, including name and address, for the candidate to complete. This information is already stored within the system, on the Contact tab of the candidate's Person profile. The name and address fields in the iForm can be set up to automatically pull in this information from the name and address fields on the Contact tab to streamline the candidate experience and cut down on time spent manually completing the form.
For more information on which profile types can be used for prepopulation of an iForm, see the
Profile Associations section of this article.
Notes:
- Only one profile field can be set per iForm field; a single iForm field cannot pull information from multiple profile fields.
- An iForm will only prepopulate the first time it is completed. Once an iForm has been completed, prepopulation settings will not overwrite any saved data, if the form is edited again at a later time.
Accessing iForms
For information on how iForms can be completed by candidates, new hires and employees, see
Accessing iForms and Requesting iForms to Be Completed.
For additional information about iForms, view the following articles:
