ICIMS disposition reasons setup is the work of deciding exactly why a candidate leaves a requisition and making sure ICIMS records that answer the same way every time. In ICIMS, the disposition reason is not a separate dropdown. It is the status a candidate lands in inside the Not Hired bin, and everything about how that status behaves is configured under Recruiting Workflow Bins and Statuses. Get the list right and your funnel reports, your candidate emails, and your compliance file all improve at once.
We configure this for talent acquisition teams as part of nearly every implementation and audit, and it is one of the highest-leverage, lowest-effort fixes in the whole system. Here is the full playbook: how disposition reasons actually work in ICIMS, the exact configuration screens, a reason list you can adapt, and the record-keeping rules that federal contractors have to design around.
The short answer
Open Admin, then System Configuration, Applicant Tracking, Workflow, and select Edit next to Recruiting Workflow Bins and Statuses. Inside the Not Hired bin, create one status per disposition reason, check the Rejected Flag on each, attach the right email through an Auto-Launch Action, and use the User Group dropdown to control which reasons hiring managers can pick. Retire old reasons with the Hidden setting rather than deleting them. Then build a report that shows every applicant on every closed requisition carries a reason.
How disposition reasons work in ICIMS 📋
Here is the thing that trips up teams coming from other systems. Many applicant tracking systems keep a separate disposition code table that you pick from after you reject someone. ICIMS does not work that way in a standard configuration. The Recruiting Workflow is organized into bins (think of them as stages), and each bin holds statuses. The Not Hired bin is where rejections live, and each status inside it is effectively a disposition reason.
So “Not Hired: Does Not Meet Basic Qualifications” and “Not Hired: Withdrew, Accepted Another Offer” are not labels on a rejection. They are the rejection. When a recruiter moves a candidate into one of them, ICIMS records the status change with a timestamp and a user, and that record is what your reports and your compliance file are built on.
That design has a real advantage. Because the reason is a status, everything a status can do, a reason can do: fire an email, require an action, block certain user groups, feed a workflow rule, and sync to an integrated system through the Rejected Flag. It also means the quality of your disposition data is decided entirely by how thoughtfully the Not Hired bin was built. In our experience, most instances still run on the statuses that were loaded during the original implementation years ago, which is exactly why the reports feel vague.
Designing the reason list before you touch the system 🎯
Do this on a whiteboard, not in System Configuration. A disposition list built by adding statuses whenever someone asks for one ends up with 40 overlapping options and no consistency. A list designed in one sitting ends up with 10 to 20 reasons that map cleanly to how your team actually decides.
Three rules we apply on every build:
- Separate employer decisions from candidate withdrawals. “Not selected” and “withdrew” are different events with different reporting and compliance meaning. Never let one status cover both.
- Tie every reason to the stage it happens at. A screening-stage reason (“does not meet basic qualifications”) should never be applied to someone who finished a final interview. Stage-specific reasons make the funnel report honest.
- Make each reason job-related and specific. “Not a fit” is not a reason. “Does not meet required certification” is. Compliance guidance on applicant tracking is consistent on this point: customize the codes to your own selection process rather than relying on generic defaults.
A starting structure that works for most mid-market and enterprise TA teams:
| Stage | Employer decision reasons | Candidate withdrawal reasons |
|---|---|---|
| Screening | Does not meet basic qualifications (experience); does not meet basic qualifications (education or certification); work authorization or location requirement not met | Withdrew before review; unresponsive to outreach |
| Phone screen | Qualified, other candidates more qualified; compensation expectations outside range | Withdrew (compensation); withdrew (schedule, travel, or location) |
| Interview | Interviewed, other candidate selected; did not demonstrate required skills in interview | Withdrew, accepted another offer; no show |
| Offer | Offer rescinded (contingency not met, such as background check) | Declined offer (compensation); declined offer (other) |
| Requisition | Requisition closed or cancelled; position filled internally | (not applicable) |
Step-by-step: ICIMS disposition reasons setup in System Configuration 🔧
These steps follow the configuration options ICIMS documents for Recruiting Workflow statuses. Do the work in a sandbox first if you have one, and do it with a written list in hand.
Open Recruiting Workflow Bins and Statuses
From the main menu select Admin, then System Configuration. In the left navigation choose Applicant Tracking, then Workflow. Next to Recruiting Workflow Bins and Statuses, select Edit. You will see the bins on the left and the configuration panel on the right.
Create each reason as a status in the Not Hired bin
Select the Not Hired bin and click the Create List Item icon (the green plus sign). A new status appears as “[New Node].” Set the Label to the reason exactly as you wrote it on your list, using a consistent prefix so the reasons sort together and read clearly in reports. Then check the Rejected Flag. This is the setting that tells ICIMS the status represents a rejection, and it is what reporting and integrations key off.
If you need vendor-facing wording that differs from the internal label, set Vendor Manager Text as well. Save after each status.
Attach the candidate communication
Each status has an Auto-Launch Action, which is the action a user completes when moving a candidate into it. For rejection reasons, set it to Compose Email and pick the matching template in Mail Template for Auto-Launch. If the email must always go out, check Auto-Launch Required. Use Auto-Launch Prompt to show the recruiter a short instruction before the action opens.
For interview-stage rejections, enable Delayed Email so the message does not land the moment the hiring manager clicks. That small delay protects candidates who deserve a call first and keeps a fast decision from reading as a dismissive one.
Control who can use which reason
Pick a group from the User Group dropdown at the top of the same screen and adjust the options. Changes made with a group selected apply only to that group. We typically hide compliance-sensitive reasons (anything involving background checks or work authorization) from hiring manager groups so those dispositions are only ever applied by recruiters who own the documentation. Your ICIMS login groups setup decides who belongs to which group, so review that alongside this step.
Retire the old reasons without deleting history
Legacy statuses that no longer belong on the list get the Hidden setting, which retires them so they no longer display when advancing or rejecting candidates. If you want the status visible for historical filtering but closed to new candidates, use Read Only instead. Either way, the records of candidates already sitting in those statuses stay intact, which is the point.
Build the report that proves it worked
A disposition setup is only done when you can run one report and see, for every closed requisition, every applicant with a reason and no one left sitting in an active bin. Build it by requisition and by stage, then add a second view grouped by reason so leadership can see why candidates are exiting. Our guide to building ICIMS recruiting reports leadership will use covers the mechanics.
Want a second set of eyes on your Not Hired bin?
We review disposition reasons, workflow bins, and reporting as part of every ICIMS audit, and we can usually tell you in one call whether your data would hold up.
Book a discovery callOFCCP, the Internet Applicant rule, and record retention 📊
If your company is a federal contractor, disposition reasons are not just a reporting nicety. They are how you show who counted as an applicant and why each one was not selected. Two rules shape the design.
The Internet Applicant definition. Compliance guidance describes four conditions that make someone an applicant: the person submits an expression of interest for a specific position, the employer considers that person for the position, the person’s expression of interest shows they meet the basic qualifications, and the person does not withdraw before receiving an offer. Your disposition reasons need to let a recruiter say, for every record, which of those conditions was or was not met. That is why “does not meet basic qualifications” and “withdrew” have to be their own reasons rather than blended into a generic “not selected.”
Record retention. Under 41 CFR 60-1.12, contractors must preserve personnel and employment records, including those relating to applicants, for not less than two years from the date of the record or the personnel action, whichever is later. Contractors with fewer than 150 employees or without a Government contract of at least $150,000 keep them for one year. The regulation also requires records of resume database searches, including the position, the substantive search criteria, and the date. In ICIMS terms: never delete a status that has history behind it, and make sure your reporting can reproduce dispositions for at least two years back.
One more note. This post describes how to configure ICIMS so your records are complete and consistent. It is not legal advice, and your compliance counsel should own the final reason list and retention policy. Our job is to make the system carry out whatever they decide, cleanly.
Five mistakes we see most in ICIMS disposition setups 🔥
- Statuses without the Rejected Flag. The candidate looks rejected on screen, but reports and integrations treat the record as still active. Audit every Not Hired status for the flag.
- One reason list for every user group. Hiring managers should not be choosing between twelve compliance-loaded reasons. Give them three and let recruiters own the rest.
- Deleting instead of hiding. Removing a status with candidates in it damages history you are required to keep. Hidden exists for a reason.
- Emails attached to the wrong stage. An instant auto-email on an interview-stage rejection reads as cold. Use Delayed Email there and reserve instant sends for screening.
- Nobody owns the list. Reasons drift as recruiters change. Assign an owner, review the list twice a year, and check the “Other” share every quarter. If no one on the team has time to own it, that is exactly the gap our ICIMS consulting engagements are built to close.
What to do next 🎯
Export your current Not Hired statuses, count how many dispositions from the last twelve months fall into each one, and look at the top three. If the largest bucket is a vague one, you have found your project. It pairs well with a broader look at system health; the signs in our ICIMS system audit red flags post usually show up in the same instances where disposition data has gone soft.
Frequently asked questions
Get more from your ICIMS investment
From disposition design to the reports that prove it, FlowFam works alongside your team and ICIMS Professional Services to make the system carry your process cleanly.
Book a discovery call
