Fiction. It’s Fiction.
There are plenty of times you want iForms to display data pulled from a profile—things like Salary, Job Title, or Department—without letting the recipient change it. Seems simple, right? Just prepopulate those fields and mark them “read only.”
If only.
Let’s walk through how this actually works in iCIMS, and how to avoid some easy-to-miss pitfalls that can seriously derail your forms—and your data.
The Promise of Prepopulated Fields
iCIMS iForms support prepopulations, which allow you to pull information directly from profile fields into the form. It’s one of the more powerful (and widely used) tools in the system. Offer letters, onboarding forms, internal approvals—they all rely on this.
And it makes sense: the data already lives in iCIMS, so why ask someone to re-enter it manually? You just want it to show up and stay put.
But here’s where it gets tricky.
The “Read Only” Trap
When you want fields to be visible but not editable, your first instinct might be to section them off using iForm sectioning. Sectioning lets you show or hide fields based on a user’s group permissions.
In theory, it works. You can create a section just for Hiring Managers or Recruiters—any user group in iCIMS—and restrict those fields from other users, like candidates.
But there’s a catch: candidates don’t have user groups. Not really. They’re automatically assigned to the “Default” section unless you manually specify something else in the form request.
So here’s what happens:
- You create a section with prepopulated offer info (like salary and start date).
- It’s hidden from the candidate’s section, but they still see the info when the form loads.
- Then they hit “Save.”
- The form saves, and you see the data on the form, but it’s not really there.
It’s not gone from the platform—but from the back-end of the form. Because it wasn’t part of their editable section, iCIMS wipes it when the candidate saves. That data doesn’t get written to the form record at all.
If someone reopens the form later and the profile has changed, it’ll show updated data instead of the original offer info. Now you’ve got discrepancies. Confusion. Risk.
That’s not just a bad user experience—it’s a compliance problem.
The Workaround: Lock It in Before Sending
The fix isn’t complex. It just requires a little planning:
- Give the user group that sends the form (e.g., Hiring Manager, Recruiter) access to the “read only” section.
- Have them open the iForm before sending it to the candidate.
- They click Edit, verify the offer data, and Save the form.
Once they’ve saved it, that data is written to the form record. The candidate can then fill out their section, and your offer data stays intact.
Need help mapping user groups or permissions? This is where iCIMS consulting really pays off.
Why This Matters for iCIMS ROI
This may seem like a small issue, but it speaks to something bigger: how iCIMS behaves behind the curtain, and what that means for your processes.
Incorrectly configured iForms can result in missing offer data, inconsistent documentation, or even legal exposure if you can’t verify what was actually offered and accepted.
That’s why it’s critical to invest in your iCIMS configuration—not just during implementation, but throughout the life of your system. If you’re looking to maximize iCIMS ROI through optimization, this kind of fine-tuning is exactly where the gains live.
Can This Be Automated?
Not at the moment.
There’s no built-in automation that lets iCIMS pre-save those fields or “lock” prepopulated data behind the scenes. You need a human to click “Edit” and “Save.” But that step takes less than 30 seconds and avoids hours of confusion or rework later.
If you’re working with high-volume hiring or distributed teams, iCIMS managed services can help embed that step into your workflow without adding manual friction.
Want more insights like these?
FAQ
Can iForm fields be made read-only for candidates?
Technically, yes—but only by using sectioning. And because candidates don’t belong to user groups, they can’t “own” a section. That makes true read-only behavior tricky without a manual workaround.
How do I prevent data from disappearing in iForms?
Have a user in the correct group (like a Hiring Manager) open, edit, and save the iForm before sending it to the candidate. That ensures the prepopulated data is stored in the form.
What happens if the candidate saves the form without editing?
Any sectioned fields they don’t have access to will not be saved—even if they were visible when the form loaded. Those fields display when saved, but they’re not actually on the form.
Can iCIMS be customized to make this process easier?
Yes. With help from iCIMS consultants, you can redesign your form structure, permissions, and workflows to prevent data loss and make the process smoother for all users.
Does this affect iCIMS ROI?
Absolutely. Every time you avoid rework, miscommunication, or manual cleanup, you’re improving efficiency. These are exactly the types of issues that drag down iCIMS ROI if left unaddressed.


