iCIMS Workflow Profiles Setup: A Consultant’s Complete Guide
Tabs, sections, fields, portal mappings, and the 5 mistakes we see in almost every messy iCIMS instance.
iCIMS Workflow Profiles setup is one of those decisions that quietly runs everything else in your ATS. Get it right at go-live and your career portals, login groups, workflow rules, and reporting all line up. Get it wrong and you spend the next two years patching symptoms that all trace back to the same place: a profile structure that never matched how the team actually hires.
This guide walks through how we configure Workflow Profiles for mid-market and enterprise TA teams as a certified iCIMS implementation partner. We’ll cover the data model, the Tabs and Sections hierarchy, multi-brand patterns, how profiles talk to portals and login groups, and the five mistakes we keep finding when we run an audit.
📋What’s in this guide
- What is an iCIMS Workflow Profile (and what is it not)?
- The anatomy of a Recruiting Workflow Profile
- Designing your Workflow Profile architecture
- Step-by-step Workflow Profile setup
- Mapping Workflow Profiles to career portals
- Workflow Profiles and login groups
- The 5 most common Workflow Profile mistakes
- FAQ
🎯What is an iCIMS Workflow Profile?
A Workflow Profile in iCIMS is the configuration container that defines the tabs, sections, fields, workflow rules, postable fields, and candidate experience for a specific type of job. Every job in iCIMS is assigned exactly one Recruiting Workflow Profile, and that profile dictates what recruiters, hiring managers, and candidates see and do for that requisition.
That’s the short answer. Now let’s unpack why it matters.
iCIMS organizes data using a few related profile types. The two you’ll touch most often when configuring jobs are the Job Profile (the requisition record itself) and the Recruiting Workflow Profile (the structure and rules that govern how candidates move through that job). According to iCIMS developer documentation, the Recruiting Workflow is the connection between a Job Profile (the baseProfile) and a Person Profile (the associatedProfile). It’s the relationship layer that makes “this candidate is in this stage for this job” a real thing.
So a Recruiting Workflow Profile is a template, and the Recruiting Workflow is the live instance of that template wrapping a specific candidate against a specific job. When we talk about “configuring Workflow Profiles,” we mean configuring the templates.
Workflow Profile vs Workflow Rule
This trips up almost every new admin we work with. A Workflow Profile is the container. A Workflow Rule (Entrance Criteria, Auto-Launch Action, or Prompt) lives inside a profile and only applies to jobs assigned to that profile. Change a profile, and you change the universe of rules a recruiter operates under for that req. If you’ve already read our piece on iCIMS Workflow Rules not triggering, this is the layer above what we were diagnosing in that post.
🧱The anatomy of a Recruiting Workflow Profile
Every profile in iCIMS follows the same Tabs > Sections > Fields hierarchy. Per iCIMS Care Center documentation on profile tab sections, no fields can be placed directly onto a tab. A section must first be created on the tab to house the fields. That structural rule sounds boring until it’s the reason your custom field never showed up where you expected.
Here’s what lives inside a Recruiting Workflow Profile:
- Tabs. The high-level groupings on the profile. Think Job Details, Workflow, Postings, Reports.
- Sections. The containers inside each tab. You can show, hide, collapse, or pin sections per login group.
- Fields. Standard and custom fields that capture data. Each field has its own type, permissions, and required/optional rules.
- Workflow Rules. Entrance Criteria, Auto-Launch Actions, and Prompts that fire when candidates change status inside this profile.
- Postable Fields. The subset of fields that get pushed to career portals when a job built on this profile is posted.
- Portal Mapping. Which career portals are eligible to display jobs that use this profile.
- Login Group Visibility. Which user groups can see and act on which parts of the profile.
One profile, seven dials. Each dial influences candidate experience, recruiter workflow, hiring manager visibility, or reporting. That’s why the profile decision sits upstream of almost every other configuration choice in iCIMS.
🏗️Designing your Workflow Profile architecture
The single most important question to answer before you click anything in System Configuration: how many profiles do we actually need?
We’ve seen instances with a single bloated profile trying to serve corporate, retail, healthcare, and contractor hiring all at once. We’ve also seen instances with 47 nearly-identical profiles because every brand insisted on its own. Both extremes cause pain. The sweet spot for most mid-market and enterprise teams is between three and twelve profiles.
Here are the splits that tend to earn their keep:
| Split type | When it makes sense | When it’s overkill |
|---|---|---|
| By brand | Multi-brand employer where candidate experience must differ visually and procedurally per brand | One legal entity, one career site, minor logo differences only |
| By hiring type | Corporate vs hourly vs contractor vs intern vs internal-only hiring follows truly different stages and approvals | Same stages across hiring types, only the approver changes |
| By country or region | Different regulatory regimes (US OFCCP vs EU GDPR), different candidate fields required, different languages | Same legal regime, language toggles only |
| By business unit | Different P&Ls genuinely run different processes (M&A holdovers, autonomous divisions) | Different cost centers, same hiring policy |
Pick the smallest set that captures truly different processes. Every additional profile is more surface area to maintain at audit time, more places workflow rules can quietly drift, and more chances for “we have eight profiles, nobody remembers which one is the right one for this req.”
The brand and hiring-type matrix
For multi-brand employers, the common pattern is a small matrix: brand on one axis, hiring type on the other. Two brands times three hiring types is six profiles. That’s manageable. Five brands times four hiring types is twenty profiles, and you should question whether the differences really run that deep before committing.
⚙️Step-by-step Workflow Profile setup
Inventory before you build
Map every job category you hire for. Note brand, country, OFCCP applicability, language, hiring stages, required intake fields, approval chain, and candidate experience differences. If two categories have identical answers across all of those, they belong on the same profile.
Clone, don’t edit from scratch
In System Configuration, find your closest-fit existing profile and clone it. Rename the clone clearly (use the convention BRAND_HIRING_TYPE so future admins can find it). Cloning preserves a known-good fallback, and lets you build the new structure without breaking active reqs that still depend on the original.
Build the Tabs and Sections structure
Decide on the tabs each profile needs (Job Details, Workflow, Postings, Approvals, Reports) and add sections inside each tab. Per iCIMS’ own field configuration documentation, fields cannot be added until at least one section exists on a tab. Build the rooms before you furnish them.
Place standard and custom fields
Add standard fields first, then custom fields. Group related fields into the same section. Use field-level permissions to hide fields from login groups that don’t need them. If you need a primer on how custom fields behave across profile types, our iCIMS data structure walkthrough covers the surrounding model.
Configure postable fields
Tell the profile which fields are eligible to be posted publicly to career portals. This is a separate configuration from “the field exists on the profile.” Skipping this step is the most common reason a custom field captures data internally but never appears on the job posting itself.
Attach Workflow Rules
Inside the profile, configure Entrance Criteria, Auto-Launch Actions, and Prompts. Scope each rule to specific login groups so the same profile can behave differently for a recruiter vs a hiring manager. Test the rules with a sample candidate before opening the profile to live reqs.
Map to portals and login groups
Add the new profile to the career portals that should display its jobs. Add it to the login groups whose users will operate on those jobs. Without these mappings, your profile exists but nothing using it will be visible or actionable.
Sandbox test, then promote
Build and test in sandbox first. Move a single live req to the new profile in production as a pilot. Watch one full hire cycle before migrating the rest of the eligible reqs. Profiles are not trivially reversible at scale, so the slow promote-and-watch loop is worth the patience.
🌐Mapping Workflow Profiles to career portals
Career portal mapping is where most “my new job isn’t showing up on the site” tickets come from. The mechanic is straightforward: iCIMS career portals can be configured to display only jobs that use specific Workflow Profiles. If your portal’s display configuration includes a Workflow Profile allowlist and a new job was built with a profile not on that list, the job will be invisible on the portal even after it is posted correctly.
We covered this exact failure mode at length in our breakdown of why iCIMS career sites stop showing jobs. The fix is to open your career portal’s configuration in iCIMS System Configuration, find the section that defines which Workflow Profiles are included in the portal’s display settings, and add the missing profile.
🔐Workflow Profiles and login groups
Login groups in iCIMS control which users can see and act on which features inside a profile. A workflow rule inside a profile can be scoped to specific login groups, which means the same profile can behave differently for a recruiter, a hiring manager, and an HRBP looking at the same req.
Three patterns we keep using:
- Recruiter group. Sees all workflow rules, all tabs, and can edit most fields. Owns the candidate motion end to end.
- Hiring manager group. Sees a stripped-down tab set, can see candidates in interview-ready statuses only, and triggers approval and feedback prompts.
- HRBP / Compliance group. Read-mostly. Sees the full profile for audit purposes, but write actions are restricted to disposition codes, EEO fields, and approval steps.
If a rule is configured to appear only for users in a specific login group, users in other groups will never see it. The fastest diagnostic for “why doesn’t this prompt appear for me” is to log in as a user in the affected group and confirm. For the full setup on login groups themselves, see our companion guide on iCIMS login groups setup.
🚫The 5 most common Workflow Profile mistakes
Editing the default profile instead of cloning it
The default Workflow Profile that shipped at go-live was your safety net. Editing it directly removes that net and can affect every legacy req still pointing at it. Always clone, rename, then edit the clone.
Building one mega-profile to serve everyone
“We’ll just toggle field visibility per login group” sounds clever and is almost always painful at year two. The profile bloats, workflow rules accumulate, and nobody can describe what the profile actually does. Split the profile when hiring processes truly diverge.
Forgetting portal mapping after a new profile is created
The job posts, the requisition status is correct, and the role is still invisible on the career portal. Nine times out of ten, the new profile was never added to the portal’s allowlist.
Same field, different IDs across profiles
“Department” lives as a free-text field on one profile and a dropdown on another. Now your reporting is comparing apples to a different fruit. Standardize critical reporting fields across every profile before launch. This is the same governance problem we describe in detail when scoping an iCIMS system audit.
Skipping sandbox validation
Profile changes look small in the UI and behave like architecture changes in practice. Build new profiles in sandbox first, dry-run a candidate through the full lifecycle, then promote. Skipping this step is how a Friday afternoon profile tweak becomes a Monday morning incident.
Need a hand with iCIMS Workflow Profiles?
We help mid-market and enterprise TA teams clean up Workflow Profile structure, align profiles to portals and login groups, and migrate to a maintainable architecture without disrupting active reqs.
Book a free discovery call💬FAQ
Ready to fix your iCIMS Workflow Profiles?
Talk with a certified iCIMS implementation partner about cleaning up profile architecture, fixing portal and login group mappings, and getting more from your iCIMS investment.
Book a free discovery call
