ICIMS Reports Not Showing Data: 7 Causes and Fixes

A recruiting leader opens the pipeline report before a Monday staff meeting and it is empty. Or it has 40 rows when there should be 400. Or the time to fill number is zero for a quarter in which the team clearly made hires. When we get the message “ICIMS reports not showing data,” the platform is almost never missing the data. The search is asking for it in a way that excludes it, or the user running it is not allowed to see it.

This post walks through the seven causes we check, in the order we check them, with the exact setting or screen behind each one. If you want the foundation first, our guide to building ICIMS recruiting reports leadership will use covers how Person, Job, and Recruiting Workflow searches fit together.

A 5-minute triage before you touch anything

Before you edit a single filter, answer three questions. They cut the list of possible causes in half.

Then do the single most useful thing in ICIMS reporting: open the search template, remove every filter except one, and run it. Add filters back one at a time. The filter that empties the result is your answer, and the rest of this post tells you why it did.

Cause 1: A search lock is hiding the records

Problem. A search lock is a permissions tool that applies a hidden filter to every search a user runs. ICIMS describes it as a way to restrict a group of users to certain candidates by using specific search filters that the user never sees. If your login group carries a lock on, say, country or folder, every report you run is narrowed before the first row is returned, and nothing on the screen tells you so.

Impact. The report looks complete but is not. A regional TA lead sees only her region and assumes the rest of the company made no hires. A new recruiter placed in the wrong login group sees zero candidates and files a support ticket about “missing data.”

Example. The telltale symptom is a profile that a user can find by ID but cannot open, with a message that access is restricted due to search locks. When we see that message in a ticket, we stop looking at the report and look at the login group.

Fix. Have a user admin open the Search Locks tab in the Admin settings and review which locks apply to the affected login group. Admins can view and edit existing locks there; creating a new lock goes through an ICIMS Technical Support case. If the lock is correct and the user is in the wrong group, move the user. Our guide to ICIMS login groups setup covers how to structure groups so this stops happening.

Cause 2: Filter logic is excluding rows

Problem. ICIMS search filters are organized into groups and subgroups, and the “any” or “all” dropdown on each group decides whether conditions combine with OR or AND logic. The search operators are “is” and “is not,” plus “contains” and “does not contain” for text fields. A single wrong dropdown turns a report that should return every candidate in two statuses into one that returns only candidates who are somehow in both, which is nobody.

Impact. Zero rows, or a fraction of the expected rows, with no error. This is the most common cause we find in reports built by recruiters rather than admins, and it is also the easiest to fix.

Example. A Recruiting Workflow search with two filters: Status is “Interview: Onsite” and Status is “Interview: Phone.” With the group set to “all,” the search requires both to be true of the current status at the same time. Result: empty. Set the group to “any” and the rows return.

A second version of the same problem is the folder filter. Candidate searches include every person who has ever been a candidate. If someone added a Person Folder filter of “Cand: Active” to trim the list, anyone who has since moved to a hired or archived folder drops out of the report, including the very hires you are trying to count.

Fix. Open the template and read each group’s any/all setting aloud as a sentence. “Return records where ANY of these statuses match” is usually what you want for stage lists; “ALL” is for stacking unrelated conditions like Recruiter and Department. Use subgroups when you need both kinds of logic in one search. Remove folder filters unless you have a specific reason to keep them.

Cause 3: A dynamic filter points at a blank profile field

Problem. Dynamic filters are how one saved template serves many users: the filter reads a value from the running user’s own Person profile (their recruiter assignment, their department, their location) and applies it at run time. ICIMS documents the catch plainly: if the profile field the dynamic filter references is not completed on the user’s profile, the template returns no results, or returns incorrect ones.

Impact. The template works for the admin who built it and for most of the team, then fails for the one person whose profile was set up in a hurry. That person concludes the report is unreliable and stops using it.

Example. A “My Open Reqs” dashboard panel filters Job: Recruiter dynamically against the viewer’s profile. A recruiter who transferred from another business unit has a blank Department field. Her panel is empty every morning, while the recruiter at the next desk sees 30 jobs.

Fix. Open the affected user’s Person profile and complete every field that any dynamic template references. Then add “dynamic filter fields” to your user provisioning checklist. This is a five-minute fix that saves weeks of mistrust, and it is one of the first things we standardize in an ICIMS system audit, because it fails quietly and repeatedly.

Cause 4: The status is missing its reporting flag

Problem. Every recruiting workflow status in ICIMS carries a set of attributes that reporting depends on. The Hired flag tells the system that moving a candidate into that status counts as a hire for time to fill reporting and for decrementing openings on the job. The Rejected flag does the same for rejection reporting, and the Interview flag marks statuses that represent scheduled interviews. A status can also be marked Hidden, which retires it from use and removes it from searches and reports entirely.

Impact. This is the cause behind most “wrong number” reports. Time to fill reads zero hires for a quarter. The offer acceptance rate is inflated because declines were never flagged as rejections. Interview volume is undercounted because a custom “Panel Interview” status was created without the Interview flag.

Example. A team creates “Hired: Contingent” to handle contractor conversions. The admin copies the label but not the attributes. Six months later, leadership asks why contingent hires never appear in the quarterly hiring report. They were hired. The system was never told.

Fix. Audit every status in the recruiting workflow against its intended flag. Any status a human would call “hired” needs the Hired flag; any status that ends a candidacy needs the Rejected flag. Confirm that no status you still report on has been set to Hidden. If you use multiple workflow profiles, repeat the audit per profile; our ICIMS Workflow Profiles setup guide explains how status sets diverge across profiles.

Cause 5: The date filter is on the wrong field

Problem. ICIMS profiles carry many dates: the date a job was created, the date it was approved, the date a candidate applied, the date of each status change, the hire date. A report filtered on “last quarter” is only correct if it is filtered on the right one of those. A hires report filtered on application date will miss every candidate who applied in a previous quarter and was hired in this one, which for professional roles is most of them.

Impact. Numbers that are plausible but wrong, which is worse than an empty report. Leadership makes decisions on a hires count that is really an applies count.

Example. A scheduled weekly report uses a fixed date range someone typed in during a demo in March. It has been faithfully emailing March’s data every Monday since.

Fix. For every date filter, ask “which event am I counting?” and filter on that event’s date. For anything scheduled or placed on a dashboard, use the relative date parameters ICIMS provides (the {DATE:START} and {DATE:END} style variables documented in the Searching and Reporting FAQ) so the window rolls forward automatically instead of freezing on the day the template was saved.

Cause 6: The filter value no longer matches the data

Problem. A filter compares a value you chose against values stored on records. When the list behind a field grows past 100 values, ICIMS stops showing a dropdown and shows an open text field instead. From that point, the value must be typed exactly. “Referral” does not match “Employee Referral.” A trailing space does not match anything. And when an admin renames a source, department, or location, every saved template still carrying the old spelling starts returning zero rows the same day.

Impact. Reports that were correct for a year go empty after routine list maintenance, and nobody connects the two events.

Example. Source reporting is the classic case. The source list passes 100 entries, dropdowns become text fields, and three recruiters each type the source slightly differently in their own saved searches. Each report is right for a different slice of the truth.

Fix. When a filter is a text field, copy the value from an actual record rather than typing it. Keep field value lists short and governed, and when you rename a value, search your saved templates for the old one before you save the change. For the source list specifically, our ICIMS source tracking setup guide shows how to keep the list reportable as it grows.

Cause 7: The dashboard panel or analytics view is the problem

Problem. Sometimes the search is fine and the surface displaying it is not. Dashboard panels and widgets can only reference search templates that have already been saved to the system. If the template behind a panel was deleted, replaced, or returns zero rows for the viewing user, the panel is blank and quick link buttons tied to it are grayed out. Analytics dashboards have their own behaviors: filters reset to defaults every session, some tiles use a unique count while others use a total count, and for CRM and CXM data, changes can take up to 24 hours to be reflected.

Impact. A VP compares a dashboard tile to an exported report, gets two different numbers, and trusts neither.

Example. A recruiter updates 50 CRM records on Tuesday morning. The Tuesday afternoon analytics review shows last week’s numbers. Nothing is wrong; the data has not landed yet.

Fix. For a blank dashboard panel, open the underlying template and run it as the affected user; fix the template, not the panel. For analytics mismatches, check whether the tile is a unique or total count before comparing it to a search export, and give CRM changes a day before escalating. Our ICIMS analytics dashboard guide covers what each surface is good for.

Related: too much data instead of too little

The opposite complaint lands in the same inbox: “the report shows the same candidate five times.” Two behaviors explain nearly all of it, and both are by design.

First, history columns in a Recruiting Workflow search return one row for each status a person was ever in, because the search engine displays every status in the history. Second, some columns can hold more than one value on a single profile, so the row repeats once per value. If you want one row per candidate, swap history columns for current status columns, or group the output by candidate.

And if a large export fails on the way into Excel, check for long text fields: Excel caps a single cell at 32,767 characters, and a notes or description column can exceed that.

How to keep reports trustworthy

Every cause above is a configuration or governance gap, not a platform gap, which means each one is preventable. These are the five habits we put in place on the instances we manage.

If the team does not have the hours for that review, it is exactly the kind of recurring work an ICIMS reporting consultant takes off the admin’s plate on a flat monthly basis, so leadership gets numbers it can act on and the admin gets their Mondays back. Reliable reporting is also where the return on the platform becomes visible; the measured ICIMS ROI results we publish all started with reports that leadership could finally trust.

Frequently asked questions