Deleting a Job Description Doesn't Delete the Candidates In It

A TA lead at a Bangalore services firm emailed us in July asking why a candidate’s interview record had “vanished” after she cleaned up old job descriptions from a finished drive. It hadn’t vanished. It was sitting exactly where it had always been, attached to a JD that no longer showed up in her active list because she had deleted it days earlier. The candidate’s score, transcript and verdict were all still there. She just couldn’t find them, because in her mental model, “delete” meant gone.

That gap between what a delete button does and what people assume it does is the entire reason job description deletion in HireQwik doesn’t delete anything. It archives. Here’s what that means in practice, why it works this way, and what actually shows up on screen before you click confirm.

What “delete” actually does

Click delete on a job description in HireQwik and the JD gets archived, not removed. It stops appearing in your active Jobs list and in the JD picker when you’re setting up a new trigger. Everything downstream of it, every candidate row, every interview, every transcript and score tied to that JD, stays exactly where it was.

This is a deliberate choice, not a missing feature. A hard delete on a JD that has already screened candidates would either cascade into deleting their interview records too, or leave those records pointing at nothing, an orphaned reference with no JD behind it. Neither is acceptable once real screening data exists. The fix isn’t a warning dialog asking “are you sure?”, since recruiters click through those without reading them the same way everyone clicks through cookie banners. The fix is making the destructive action itself non-destructive.

The guard that shows you what’s actually attached

Before an archive goes through, HireQwik checks what’s connected to that JD, how many candidates currently sit in the inbox against it and how many interviews reference it, and shows that count on the confirmation step. A JD with zero candidates archives with nothing to think about. A JD from a live campus drive, still hundreds deep in the pipeline with most interviews not yet run, shows that scale before you commit, instead of a generic warning that reads the same either way.

That distinction matters more than it sounds like it should. “Delete this job description” reads the same whether it’s an empty draft you created by mistake five minutes ago or a live campus drive with hundreds of people mid-screen. The guard makes the difference visible at the moment it matters, not after.

We built this after watching a pattern in our own pilot data: JDs got cleaned up in batches, usually at the end of a hiring cycle when someone was tidying the Jobs page, and the person doing the tidying rarely had the candidate counts memorized. A guard that surfaces the real number, right before the click that would otherwise be irreversible, replaces a memory problem with a visible one.

Why a hard delete was never the right default

The argument for a hard delete is simple: it’s tidy. An empty Jobs list with only current roles in it is easier to scan than one cluttered with everything you’ve ever posted. We considered it and rejected it, for a reason that has nothing to do with tidiness and everything to do with what a JD actually is once candidates have been screened against it.

A job description in HireQwik isn’t just a form. Once a trigger runs against it, it becomes the anchor for a per-JD scoring rubric, a set of phase-0 knockout questions, and every interview conducted under it. Deleting the JD without a trace would mean a candidate’s evaluation exists with no explanation of what they were evaluated against. Six months later, when someone asks “why did this candidate get rejected,” the honest answer requires the JD that produced the verdict, not just the verdict itself.

NIST’s definition of data integrity puts the general principle plainly: information must not be improperly modified or destroyed, and that guarantee has to hold for the context a record depends on, not only the record itself. An orphaned interview record, disconnected from the JD it was scored against, fails that test even if the score itself is still technically stored somewhere. Archiving instead of deleting keeps that trace intact by construction, rather than relying on someone remembering to export a copy before cleaning up.

Archived doesn’t mean invisible to everyone

Archiving a JD removes it from the places you’d use to set up new work: the active Jobs list, the trigger picker, the inbox filters you’d use day to day. It doesn’t remove the underlying record. An interview conducted against an archived JD still opens normally from the candidate’s own history, still shows the two-evaluator scorecard it produced, and still carries whatever label that JD had, including a disambiguated one if it once shared a title with another role.

That last point connects to a problem we wrote about separately: when two JDs parsed from the same document get the same role title, HireQwik appends a suffix so they stay distinguishable in the inbox filters. Archiving a JD doesn’t undo that label. If you archive one of two “Software Engineer, Bangalore” roles, the surviving JD doesn’t quietly revert to the plain “Software Engineer” title; the label stays exactly as it was set. The archive step and the disambiguation step are separate mechanisms solving separate problems, and neither one resets the other.

Archiving a JD is not the same action as stopping a campaign

It’s worth being precise about a distinction that gets blurred in practice. If a live drive is misconfigured or needs to halt right now, the tool for that is stopping the campaign, which cancels scheduled interviews, revokes any invite links already emailed, and refunds unused credits. Archiving a JD does none of that. It doesn’t touch scheduled interviews, doesn’t revoke anything, and doesn’t stop a trigger that’s currently running. Archiving is a cleanup action for a JD whose active life is already over; stopping a campaign is an emergency brake for one that isn’t. Reaching for the wrong one, archiving a JD to try to halt live sends, would leave the trigger running against a JD that’s simply harder to find in your own Jobs list, which is worse than doing nothing.

The audit trail this protects, without overselling it

There’s a mundane but real scenario this design exists for: a candidate, or a hiring manager, asks months later why a specific interview scored the way it did. Answering that question honestly requires the JD the interview was scored against, its rubric, its knockout questions, exactly as they existed at the time. If deleting a JD had wiped that context, the honest answer would become “we no longer have the details,” which is not a position any of us want to be in when someone is asking a fair question about a real decision. We’ve written before about pulling raw counts out of the screening funnel for a genuine audit; none of that is possible if the JD behind a candidate’s score has been hard-deleted out from under it.

We’re not claiming this makes HireQwik compliant with any specific record-retention law; retention requirements vary by jurisdiction and by the kind of role, and that’s a legal question for your own team, not a feature we’re certifying. What we can say is narrower and still useful: the product doesn’t make the record-keeping problem worse by design, and a recruiter who archives instead of deletes isn’t accidentally destroying evidence they might need to explain a decision later.

When archiving is actually the right move

The dependents guard isn’t a reason to avoid cleaning up your Jobs list. A role you posted, ran a trigger against by mistake, and immediately corrected is a zero-candidate JD, and archiving it is exactly the right call; there’s nothing attached to lose track of. A finished campus drive from two hiring cycles ago, fully screened, fully decided, is also a reasonable candidate for archiving. The point of the guard isn’t to talk you out of archiving. It’s to make sure the number you’re looking at before you click matches the number you expect, so a 340-candidate role doesn’t get cleaned up on the same reflex as an empty one.

A useful habit for a TA team running several drives at once: archive a JD the same week a drive closes, not months later during a general cleanup pass. Closing while the candidate count is still fresh in your head means the guard’s number confirms what you already know, rather than surprising you. Waiting until the next quarter’s cleanup means every count on the guard is a small discovery, and small discoveries at scale slow a cleanup pass down.

What this looks like across a real Jobs page

Picture a TA team running several roles at once: a couple of live campus drives, a lateral requisition or two in early stages, and one JD created by accident when someone double-clicked “New JD.” The accidental one has zero candidates and archives instantly, no second thought needed. A lateral requisition that closed last week shows a small, easy-to-confirm candidate and interview count on the guard, low enough to glance at and archive without hesitation. The still-live campus drives shouldn’t be touched yet regardless of what the guard would show.

That’s the whole workflow in practice: the guard doesn’t slow down the easy cases, and it puts a number in front of you for the ones where a number actually changes your decision. A Jobs page that’s honest about what’s attached to each role is more useful than one that’s simply short.

What happens to the trigger underneath an archived JD

Archiving isn’t the only moving part attached to a JD. Most live roles also have a Google Sheet trigger wired to them, polling for new candidate rows and enriching, scoring, and inviting each one automatically. Archiving the JD stops that trigger from doing anything further, the same way it stops the JD from appearing in the trigger picker for new setups, but it’s worth being explicit about the order of operations, because the two systems fail differently if you get it backwards.

If a placement coordinator is still actively dropping new rows into a sheet connected to a JD, and you archive that JD first, new rows will simply sit unprocessed rather than erroring loudly. There’s no dramatic failure, no red banner, just silence where invites used to go out. That’s a worse outcome than an explicit error, because silence looks identical to “nothing new happened today” until someone notices candidates aren’t getting invited and starts digging. The practical fix is procedural, not technical: confirm the sheet has actually stopped receiving new rows, or that you’re intentionally cutting it off, before archiving, not after.

This is a genuinely different failure mode from the guard we described above. The dependents guard protects against losing track of candidates already screened. It says nothing about a trigger that’s still live and about to receive new rows the moment after you archive its JD. Both matter, and conflating them, assuming the archive guard covers every way a JD stays “in use,” is the kind of near-miss that’s easy to have once and never repeat.

A comparison worth making explicit

It’s worth naming the alternative most recruiters have actually lived through, because it clarifies why this design choice matters. In a tool with a genuine hard delete, the standard advice is defensive: export everything before you delete anything, keep your own backup spreadsheet, never trust the platform to remember what you did. That advice exists because the platform genuinely can’t be trusted to remember, once you’ve deleted a record, it’s gone, and the only copy left is whatever you happened to save yourself.

HireQwik’s archive model inverts that relationship. You don’t need a personal backup discipline layered on top of the product, because the product’s own behavior already assumes you might need the record again. That’s a small thing to notice in the moment you click archive, and a large thing the one time, months later, that you actually need to explain a decision you’d forgotten making.

The take

A delete button that actually deletes is the wrong default the moment real people’s interview records sit behind it. Archiving with a dependents guard costs a recruiter one extra glance at a number before an action that used to be silent and permanent. That’s a small tax to pay for never having to explain to a hiring manager why a candidate’s evaluation is gone. If you’re setting up your own Jobs page and want to see how the guard behaves on a live account, talk to us.