Jordan runs operations for a 60-person recruitment agency placing candidates across three industries, and the agency's central Candidate Tracker list in SharePoint had just crossed 38,000 items. Nobody remembered exactly when it was created. Everybody agreed it was too slow to open.
A list that grew for eight years without a plan
The Candidate Tracker started as a simple list: name, role applied for, status, recruiter, date added. Over eight years it became the agency's default place to log anyone who ever submitted a resume, interviewed, or was sourced through a cold outreach campaign that went nowhere. Recruiters added items constantly. Almost nobody deleted anything, because deleting felt risky and nobody had ownership of a cleanup policy.
By the time Jordan got involved, opening the list's default view took several seconds longer than it should, filtered views intermittently failed to load past a certain row count, and a recruiter had recently lost an afternoon trying to find one specific 2019 candidate buried among thousands of records nobody would ever contact again.
Deciding what actually needed to go
Jordan worked with the recruitment team lead to define a retention rule everyone could live with: candidates with no activity (no status change, no note, no interview) in the last three years, and a status of either "Rejected," "Withdrawn," or "No Response," were safe to remove. Active candidates, current placements, and anyone flagged as a potential future fit stayed untouched regardless of age.
Turning that rule into a query was the harder part. The list had grown organically enough that status values weren't fully consistent. Some records used "Not Selected" instead of "Rejected." A cleanup run against the wrong field values would either miss thousands of eligible records or, worse, catch something it shouldn't.
Filtering, previewing, and clearing the backlog
Jordan used ShareMaster's Space Master Bulk Delete List Items tool to build the filter: last activity older than three years, combined with any of the four status variants the team had identified. The preview step returned 22,617 matching records, which lined up closely with what the team lead had estimated from memory. That match gave Jordan enough confidence to proceed without a second manual review pass.
The bulk delete ran against the full matched set in one operation, well past the point where the native browser view would have stopped loading. Deleted items went to the site's recycle bin rather than being purged outright, which mattered because two records got flagged by a recruiter the following week as candidates worth keeping after all. Both were restored from the recycle bin inside a few minutes, no data actually lost.
What changed after the cleanup
The Candidate Tracker dropped from 38,000 items to a little under 15,500. Default views loaded noticeably faster, and the filtered views that had been intermittently failing worked reliably again. The recruiter who'd lost an afternoon hunting for a single old record could now search the remaining list and get a result in seconds rather than minutes.
Jordan also pulled a fresh export through Report Master to document the before-and-after item count for the agency's data retention file, since a couple of clients had started asking recruitment vendors how long candidate data gets kept.
Turning a one-time cleanup into a standing habit
The bigger change was procedural. Jordan and the team lead agreed on a standing rule: run the same filter (activity older than three years, closed status) twice a year, review the preview count, and clear the backlog before it builds back up to an unmanageable size. Recruiters were also asked to standardize on the four agreed status values going forward, rather than inventing new labels case by case, so the filter stays accurate without periodic relabeling work.
For teams facing a similarly overgrown list, the mechanics Jordan used are covered step by step in the guide to bulk deleting SharePoint list items.