Every week someone on a TA team tells us their ICIMS iForms are not working. A candidate says they never got the offer acknowledgement. A hiring manager opens the interview feedback form and every field is empty. A new hire submits the same tax form four times and it will not go through. The phrase “ICIMS iForms not working” covers all of these, and each one has a different cause and a different fix.
The good news: iForms are one of the most reliable pieces of ICIMS. In our experience the form itself almost never fails. What fails is the request around it, the profile type under it, or the data going into it. This post walks through the seven causes we find most often, in the order we check them on a diagnostic call, with the exact status labels and setting names ICIMS uses so you can match what you see on screen.
Start here: read the iForm status before you change anything
ICIMS tells you most of what you need to know in one column. Open the profile, go to the iForms tab, and look at the status next to the form. The ICIMS Community documents five statuses, and each one narrows the diagnosis.
| Status you see | What ICIMS means by it | Check first |
|---|---|---|
| Requested | The request email has been sent. | Cause 3 (delivery), then Cause 4 (blank fields) |
| Requested (Expired) | The expiration date on the request has passed. | Cause 2 |
| Requested (Canceled) | A request was sent and then canceled by a user. | Cause 2 |
| In-Progress | The recipient used Save & Return and has not submitted. | Cause 5, then Cause 6 |
| Completed | The form was filled out and submitted. | Cause 6 if two versions appear |
| No form listed at all | Nothing was requested on this profile type. | Cause 1 |
If you have never mapped out where iForms live in your instance, our ICIMS iForms setup guide covers the builder, profile types, and dependencies from the ground up. This post assumes the forms exist and something downstream is off.
Cause 1: You are looking at the wrong iForms tab
A recruiter swears the interview feedback form was sent. The hiring manager opens the candidate and sees no form. Both are right. They are looking at two different profiles.
An iForm is attached to exactly one profile type, and each profile type has its own tab. Per the ICIMS Community, Person forms sit on the iForms tab of the Person profile. Recruiting Workflow forms sit on the iForms (Workflow) tab, reached from the Job profile, the People tab, then the chain link icon. Job forms sit on the iForms (Job) tab of the Job profile. Onboarding Workflow forms sit in the iForms Center under the Workflows tab, Onboard section. A Recruiting Workflow feedback form will never appear on the Person profile’s iForms tab, no matter how many times it is requested.
The fix
Open Admin, then System Configuration, then iForms, and note the profile type on the form in question. Then go to the matching tab. If the form is there with a status, jump to that status in the table above. If the hiring manager still cannot see the tab at all, the issue is almost always their login group. Login groups control which tabs and buttons a user sees, and a group built for a narrow hiring manager view often hides iForms tabs it was never meant to hide. Our ICIMS login groups setup guide shows how to check what a group can and cannot see.
Cause 2: The request expired or was canceled
The candidate clicks the link in the email and gets a page that will not load the form. The status on the profile reads Requested (Expired) or Requested (Canceled).
Every iForm request carries an expiration date. Once that date passes, ICIMS marks the request Requested (Expired) and the link stops working. Requested (Canceled) means a user removed the request from the iForms tab after the email went out. Both are working as designed. The candidate is holding a dead link.
The fix
Send a fresh request. On the iForms tab, click Send iForm, select the form, and choose Request Candidate/Employee to complete this iForm (or Request 3rd Party to complete this iForm when a reference or a manager outside ICIMS needs to fill it in). The old request cannot be reactivated, and the new email carries a new link.
Cause 3: The request email never reached the recipient
The status reads Requested. The candidate says nothing arrived. Days pass and the recruiter re-sends, with the same result.
Requested confirms the email was generated. It does not confirm delivery, and it does not confirm the email contained a working link. The request email is a template, and the link inside it comes from a Form URL variable that ICIMS fills in at send time. If someone edited the template and removed that variable, or added a variable the form’s profile type cannot resolve, the candidate gets an email with no link, or a link that goes nowhere. The ICIMS Community is explicit that an unavailable variable shows with a strikethrough in the preview, and that the system warns the sender before an email with unresolved variables goes out. In a busy day that warning gets clicked through.
The fix
- Open the request email template and use the Preview link. Any variable with a strikethrough will not resolve for this recipient. Remove it or replace it.
- Confirm the Form URL variable is present. Without it there is no link, and the candidate has nothing to click.
- Check the email address on the profile. A typo in the candidate’s email is more common than any system issue.
- If the template is clean and the address is right, treat it as a deliverability question and work through our ICIMS email notifications troubleshooting guide, which covers sender authentication and spam filtering.
Cause 4: The form is on the wrong profile type
The form opens fine. The job title, requisition number, or candidate name that should be prepopulated is blank. Or the answers are captured but never show up on the profile where reporting expects them.
Each iForm is built on one of four profile types, and the profile type decides which data the form can see. A Person form can read person fields only. A Job form can read job fields only. A Recruiting Workflow form is associated with one specific person and one specific job, so it can read both. An Onboarding Workflow form reads person and onboarding data. A Person form asked to prepopulate a job title has no path to that data. The field is not misconfigured. It is out of reach.
The fix
Profile type is set when the form is created and is not something you switch later. If the form needs both candidate and job data, rebuild it on the Recruiting Workflow profile type, which is why we default to that type for interview feedback, hiring manager evaluations, and anything tied to a requisition. If the data needs to land on the profile after submission, configure Sync with Profile Field on each field that should carry over. ICIMS will not move data between layers on its own.
Not sure which of these seven is yours?
On a 30 minute discovery call we will open your iForms tab, read the statuses with you, and tell you which cause applies to your instance and what the fix looks like. One client cut ICIMS support tickets by 90% in 90 days after this kind of configuration cleanup.
Book a discovery callCause 5: A blocked character is failing validation
The recipient fills in every field, clicks submit, and gets a validation error. They try again. Same error. Nothing on the form looks wrong.
As of Release 14.2, ICIMS validates text and textarea fields by default and blocks a specific set of characters when they appear inside delimiters: the less-than and greater-than signs, single and double quotes, backslash, forward slash, and the backtick. The part that catches teams is documented in the ICIMS developer resources: an existing answer that already contains those characters causes every subsequent submission to fail. So a form that was saved with Save & Return months ago, or prepopulated from a profile field that contains a quote mark, can be impossible to submit today even though the person filling it in typed nothing unusual.
The fix
- Open the In-Progress form and scan every text field for the blocked characters. Pay attention to fields that were prepopulated from the profile, since the person filling in the form did not type those.
- Clean the offending value on the source profile field, not only on the form, or the sync will put it back.
- If the form is fed by an integration or the iForms API, check what that system is writing. Job descriptions with HTML tags and names with apostrophes are the usual suspects.
Cause 6: The form is stuck In-Progress or shows an unsigned version
A form the candidate signed last week now shows two radio buttons: Latest Signed Version and Latest Modified (Unsigned) Version. Compliance asks which one counts. Or a form sits at In-Progress for weeks and nobody can tell whether the candidate abandoned it.
In-Progress is what ICIMS shows whenever Save & Return has been used and the form has not been submitted. It is a normal state, not an error, but it looks like one on a dashboard. The two-version display appears on forms configured to require a signature every time the form is updated. The ICIMS Community notes that when a profile field is modified, the synced iForm field is modified automatically, and that change can be enough to create an unsigned version. Nobody touched the form. A recruiter corrected a start date on the profile, and the signed form quietly picked it up.
The fix
For In-Progress forms, set a follow-up cadence rather than treating the status as a defect. A short reminder email at day three and day seven clears most of them. For the two-version display, decide what the signature is meant to cover. If the signed answers must be frozen, remove Sync with Profile Field from any field that can change after signing. If the form should always reflect the current profile, keep the sync and ask the signer to re-sign after material changes. Either is a valid design. Having neither decided is what creates the compliance question.
Cause 7: Your edits to a Standard iForm were overwritten
Last quarter an admin added a custom field and a company logo to a tax form. After a release, the field is gone, the logo is gone, and the form looks the way it did on day one.
Standard iForms are maintained by ICIMS for compliance purposes, and ICIMS updates them when the underlying regulation changes. That is the feature. The consequence is that any local edit to a Standard iForm is replaced the next time ICIMS pushes an update. The form was not reverted by mistake. It was refreshed as designed, and the local changes were never part of it.
The fix
Never edit a Standard iForm directly. Duplicate it first, which creates a Custom iForm you own. Then make the changes on the copy and point your onboarding packets at the copy. The trade-off is real: the custom copy no longer receives automatic compliance updates, so someone on your team owns keeping it current. For federal forms we usually recommend leaving the Standard version alone and putting company-specific content in a separate acknowledgement form instead.
How to keep iForms working after the fix
Most of the seven causes come back if nobody owns them. These are the four practices we put in place after an iForms cleanup.
Report on iForm status weekly. A simple report of forms in Requested (Expired) and In-Progress, grouped by form name, surfaces expiration and abandonment problems before candidates complain.
Lock the request email templates. Limit who can edit them, and preview every template after any change so a missing Form URL variable is caught before it reaches a candidate.
Keep an iForm inventory. One list with form name, profile type, whether it is Standard or Custom, which fields sync to the profile, and whether it requires a signature on every update. Half the diagnostic calls we take would take five minutes with this list in hand.
Read release notes for Standard iForm updates. When ICIMS refreshes a form, confirm your packets still point at the right version and your custom copies still match the regulation.
If iForms are one of several things that feel off, the pattern usually points to a wider configuration drift, and an ICIMS system audit is the faster path than fixing forms one at a time. And if the team fixing this is one person with no backup, our ICIMS managed services put an admin on call for exactly this kind of request, on a flat monthly fee. Onboarding forms in particular tend to be worth a second look; our ICIMS onboarding setup guide covers packets and the new hire portal in depth.
Frequently asked questions about ICIMS iForms not working
Get your iForms request flow working end to end
Bring the form that is giving you trouble. We will walk the status, the template, and the profile type with you on the call, and you will leave knowing which of these seven causes it is and what to change. Flat monthly pricing, no hourly meter.
Book a discovery call
