iCIMS Data Structure Explained: A Guide for Non-Technical Teams
Person Profiles. Job Profiles. Recruiting Workflows. If you’ve ever wondered why iCIMS stores things the way it does – and why it matters – this is for you.
Most teams come to us with the same frustration: they’ve been using iCIMS for months – sometimes years – but the iCIMS data structure still feels like a black box. Automations fire at the wrong time. Custom fields show up in the wrong places. Reports pull back incomplete data. And nobody quite understands why.
The answer, almost always, is that the team never got a clear map of how iCIMS actually organizes its data. This guide fixes that. No developer degree required.
🎯 Why iCIMS Data Structure Matters
iCIMS is not just an applicant tracking system. It’s a full talent platform, and the decisions made about how data is organized inside it affect everything downstream – from the automations that send interview reminders, to the offer letters that pull candidate names, to the reports your VP of Talent wants every Monday morning.
When something breaks in iCIMS, it almost always traces back to a data structure issue. An automation doesn’t fire because the candidate is in the wrong folder. An offer letter template shows blank fields because the iform was built on the wrong profile type. A report returns zero results because the search is pointed at Person Profiles when it should be pointed at Recruiting Workflows.
Understanding the structure doesn’t mean becoming a developer. It means understanding the logic so you can configure things correctly the first time – and debug them quickly when they go sideways.
🔥 The Three Core Objects in iCIMS
Everything in iCIMS revolves around three core objects. Once you understand these and how they relate to each other, the rest starts to click.
👤 Person Profile
Every human in your iCIMS system – candidates, employees, hiring managers – lives as a Person Profile. It’s the master record for a person. Think of it as their file folder that follows them regardless of which job they apply for.
💼 Job Profile
Every open or closed requisition lives as a Job Profile. It stores everything about the position – title, location, hiring manager, posting details, approval chain. One Job Profile can be connected to hundreds of candidates.
🔗 Recruiting Workflow
This is the connection between a Person and a Job. When someone applies to a role, iCIMS creates a Recruiting Workflow record – the application itself. This is where stage tracking, interview scores, and offer details live.
The key insight is the many-to-many relationship. One person can apply to multiple jobs, creating multiple Recruiting Workflows. One job can attract hundreds of applicants, each with their own Workflow. The Person Profile stays the same across all of them – only the Recruiting Workflow changes per application.
When you’re searching for applicants in iCIMS, always search Recruiting Workflows – not Person Profiles. Searching Person Profiles shows you the person’s master record, but not which job they applied to or what stage they’re at. Workflows are where the application-level data lives.
📊 Folders: How iCIMS Classifies People
Within the Person Profile object, iCIMS uses folders to classify different types of people. A folder is essentially a category that determines what tabs, fields, and automations apply to that person record.
The most common folders you’ll encounter:
Candidate Folder
The default folder for external job applicants. People in the Candidate folder can apply to jobs, move through hiring stages, and receive automated notifications. This is your typical job seeker.
Employee Folder
Used for people who have been hired and exist in iCIMS as current employees. The Employee folder unlocks different tabs and iForms – for example, onboarding checklists and compliance documents.
Hiring Manager Folder
Used for internal users who need to participate in hiring workflows – reviewing candidates, submitting feedback, approving offers – but are not recruiters with full system access.
Sourced / Talent Network Folder
For people who have expressed interest or been added to your talent network but haven’t formally applied to a specific role. Often used with iCIMS Engage (the CRM module) for proactive sourcing.
Folder assignment matters more than most teams realize. Workflow automations – including the ones that trigger background checks, send offer letters, and kick off onboarding – are often scoped to specific folder types. If a candidate ends up in the wrong folder (which can happen during imports), automations won’t fire even if the stage is set correctly.
A person can also exist in multiple folders simultaneously – for example, a current employee who refers themselves for a different role might have both an Employee folder and a Candidate folder attached to their Person Profile.
✅ Panels and Fields: Where Your Data Actually Lives
Inside every profile – whether it’s a Person Profile, Job Profile, or Recruiting Workflow – data is organized into panels and fields.
Panels are the sections that group related data together. Think of them as collapsible headings on the profile view: “Basic Information,” “Contact Details,” “Education,” “Background Check Status.” Panels are mostly for visual organization, but they also control who can see what – access permissions in iCIMS are often set at the panel level.
Fields are the individual data points within each panel. iCIMS supports several field types:
| Field Type | What It Stores | Common Uses |
|---|---|---|
| Text (single-line) | Short free-text strings | Phone number, job code, cost center |
| Text (multi-line) | Longer free-text blocks | Interview notes, recruiter comments |
| Dropdown (single-select) | One option from a defined list | Department, location, rejection reason |
| Dropdown (multi-select) | Multiple options from a list | Skills, languages, certifications |
| Date | Calendar date | Offer date, start date, screening date |
| Numeric | Numbers | Salary, years of experience |
| Yes/No (checkbox) | Boolean true/false | Relocation available, background consent |
Custom fields can be added by your iCIMS administrator. But here’s the critical thing: a field can only exist on one profile type. A custom field built for the Person Profile cannot be accessed by the Job Profile, and vice versa. This matters enormously when building iForms and reports.
🚀 Workflow Profiles and Stages
When a candidate enters a Recruiting Workflow (i.e., applies to a job), they move through a sequence of stages. The structure of those stages is controlled by something called a Workflow Profile.
A Workflow Profile is essentially a template that defines:
- Which stages exist in this hiring process (Applied, Phone Screen, Interview, Offer, Hired, etc.)
- What automations and notifications fire at each stage transition
- Which iForms are available at each stage
- What the “hired” and “rejected” terminal stages are
Most organizations have multiple Workflow Profiles – one for corporate salaried roles, one for hourly/frontline hiring, maybe one for executive search. Each can have a completely different stage structure and set of automations.
Workflow Profiles are assigned at the Job Profile level. When you create a new requisition and select the job type or hiring category, iCIMS uses that to assign the correct Workflow Profile to all candidates who apply to that job. Mis-assigning a Workflow Profile is a common cause of automations not firing correctly – especially when jobs are manually created instead of built from templates.
📋 iForms and Profile Type: The Invisible Constraint
iForms are electronic forms that collect additional data inside iCIMS. They can be completed by candidates, employees, or hiring managers as part of the hiring or onboarding process. Common examples include EEO forms, offer letter data-collection forms, interview scorecards, and I-9 initiation forms.
But here’s where many teams run into trouble: every iForm is built on a specific profile type, and that choice determines what data the form can access.
| Profile Type | Can Access | Cannot Access | Best For |
|---|---|---|---|
| Person Profile | Candidate name, email, phone, EEO data, resume fields | Job title, department, salary range, hiring manager | EEO forms, background consent, contact updates |
| Job Profile | Job title, department, location, hiring manager | Candidate data | Requisition details, job approval forms |
| Recruiting Workflow | Both candidate data AND job data | N/A – most comprehensive option | Interview scorecards, offer letters, screening forms |
The most common mistake we see: teams build an offer letter iForm on the Person Profile because that’s where the candidate lives. Then they wonder why the offer letter template can’t pull the job title or salary range. The answer is profile type. Offer letters need data from both the candidate and the job, so they have to be built on the Recruiting Workflow profile type – not the Person Profile.
You cannot change an iForm’s profile type after it’s been created. If you discover a form was built on the wrong profile type, you have to rebuild it from scratch. This is one of the most expensive configuration mistakes to fix mid-implementation – it means recreating logic, retesting, and potentially migrating historical data.
Is Your iCIMS Configured the Way It Should Be?
Most teams don’t find out about structural issues until something breaks. We do iCIMS architecture reviews that catch these problems before they cost you time – and before they create compliance gaps.
Book a Free iCIMS Review⚠️ Common iCIMS Data Structure Mistakes (And How to Avoid Them)
Understanding the iCIMS data structure isn’t just academic – it’s the difference between a system that runs smoothly and one that requires constant firefighting. Here are the structural mistakes we see most often.
Building iForms on the Wrong Profile Type
As covered above – this is the most common and most expensive mistake. Always plan which data you need before creating the form. If you need both candidate and job data, the form must be a Recruiting Workflow iform.
Ignoring Folder Types During Imports
When importing candidate data from another ATS, teams often skip folder assignment. Candidates end up in a generic folder that doesn’t match any of your automation rules. Always map folder type as part of any import or data migration.
Creating Custom Fields in the Wrong Location
A custom “Salary Expectation” field built on the Person Profile can’t be referenced by reports that search Workflows. Decide upfront whether a field is about the person or about the application – and create it on the correct object type accordingly.
Duplicate Person Profiles
When the same candidate applies with a different email address, iCIMS creates a second Person Profile. Over time this causes reporting inaccuracies, double notifications, and messy sourcing attribution. Implement a duplicate-check process during application intake and clean up duplicates monthly using iCIMS’s merge tool.
Assigning the Wrong Workflow Profile to a Job
If a corporate salaried role accidentally gets assigned the hourly Workflow Profile, none of the standard interview automations, offer templates, or scoring forms will show up correctly. Always use job templates when creating new requisitions – they carry the correct Workflow Profile assignment automatically.
❓ Frequently Asked Questions
Ready to Get Your iCIMS Running the Way It Should?
Whether you’re mid-implementation or years in with structural debt, we help teams clean up their iCIMS configuration and build workflows that actually hold together. Let’s talk.
Book a Free Discovery Call
