Recruitment & Onboarding
Closing rejected applications with a record
Published 9/24/2026 · Updated 9/24/2026 · Dayzen
Closing a rejected application means recording a terminal no against that job, with a reason, owner, and date, then communicating if your process says you will. Do not leave people in Interview forever. This is record-keeping, not discrimination-law advice. Stage design stays on the pipeline article; the hiring checklist owns the forward path.
Key takeaways
- Terminal state + reason + owner.
- Not POSH or discrimination legal advice.
- Not a second hiring checklist.
Closing a rejected application means recording a terminal no against that job, with a reason, an owner, and a date, then communicating if your process says you will. It is record-keeping so the requisition and the audit trail both end cleanly. People should not sit in Interview forever because nobody wanted to click reject. This page owns that terminal state. Designing pipeline columns stays on hiring pipeline stages. The forward hiring path stays on the recruitment hiring checklist. Product context is Dayzen recruitment. This is not discrimination-law advice, not POSH advice, and not a claim that one nationwide rule tells you what reasons you may store.
A rejection is not a silent disappearance from the board. If the person vanished from a column with no reason, you have not closed the application. You have lost it. Later you cannot answer the candidate, the hiring manager, or a rehire question with anything but a shrug.
Terminal means this application, this job
Rejected is a state of an application, not a lifetime ban on a human. The same person can be rejected for Role A and still be live for Role B. They can reapply later to Role A if you allow it. Closing should not merge them into a global “do not hire” list unless you have a separate, governed process for that — and even then, it is not this article’s job to invent that list.
Pipeline stages already treat hired, rejected, and sometimes withdrawn as terminals. This page does not redesign those names. It specifies what must be true when you choose rejected:
- The application is no longer in a live decision stage (Applied, Screen, Interview, Offer).
- A reason exists that you are willing to stand behind internally.
- A named owner made the close (recruiter of record or hiring manager, as you assign).
- A timestamp exists so “we declined them in March” is a fact.
- Communication is either sent, scheduled, or explicitly marked as not sent under a written rule — not forgotten.
Withdrawn is a sibling terminal: the candidate declined, accepted elsewhere, or went silent after a timeout you published. Do not code withdrawn as rejected if you want reporting to tell those apart. Do not code rejected as withdrawn to feel kinder in a dashboard. Pick the word that matches what happened.
Reasons you can report without writing a novel
Freeform essays do not aggregate. Empty reason codes get filled with jokes. Publish a short list aligned to how you actually screen, for example:
- Skills or experience versus the job description must-haves.
- Compensation expectations outside the approved band.
- Location or shift mismatch the posting already stated.
- Incomplete application after a documented follow-up.
- Duplicate application for the same job (keep one live row).
- Role filled / requisition closed (remaining people need a close, not a freeze).
- Candidate not a fit for this role after interview evidence — pointing at filed feedback, not a vibe.
Keep the list boring. Do not encode protected characteristics. Do not write amateur legal theories into the reason field. If interview feedback exists, the reason can be a code plus a pointer to those notes. The feedback article owns how notes are structured; here you only need a close that is consistent with those notes. Closing as “skills” while the only filed remark says “we never met them” is a lying record.
Hiring managers often want a private paragraph. Allow an internal note for the file. Do not put that paragraph in the candidate email. The email, if you send one, should be the communication you actually intend to send — short, factual, not a recap of scores.
Owner and date are not bureaucracy
Without an owner, reject becomes “someone thought we were done.” Without a date, ageing reports lie. The owner is the person accountable for the decision on that application, usually:
- Recruiter at Screen, when the CV will not proceed.
- Hiring manager after Interview, when feedback is in and the decision is no.
- Recruiter when the job is filled and remaining applications must leave the live board.
If a panel disagreed, the decision owner still records the organisational no and leaves the individual remarks intact. Do not delete dissent to make the close look tidy. Do not leave the application in Interview because the panel was messy. Messy evidence plus a dated decision is still a close. Messy evidence plus no close is a parking lot.
Backdating is a habit to refuse. If you forgot to reject for two weeks, close today and, if needed, note that the decision was reached earlier. Pretending the click happened on the interview day falsifies ageing and any later audit of how long people waited for news.
Communication is a process rule, not a mood
Decide, per stage, whether a rejected applicant is notified, with which template, and within what internal SLA you publish. The pipeline article already asks you to write that per column. This page insists the close event and the mail (or the explicit “no mail”) are coupled.
Typical patterns teams actually run:
- Screen rejects: a short template, often batched, so Applied does not become a graveyard of silence.
- Post-interview rejects: a more personal note from recruiter or manager, still templated enough not to invent new facts.
- Role filled: a “position closed” note to everyone still live, including people you liked, so they are not waiting on a job that no longer exists.
You may choose not to notify at very early spam or incomplete-form stages if that is written down. What you may not do is tell the board “we always inform” while the inbox stays empty. Ghosting is an operating failure even when it is common. This is not a legal conclusion about what every employer must send. It is hygiene: the record should show whether you intended to communicate.
Do not use the reject email to debate the candidate’s worth. Do not attach interview scorecards. Do not promise a talent pool you will not maintain. If you might reopen them for another job, say you will keep their application on file for other openings only if that is true and you will actually search that file.
Requisition close versus application close
Filling a job is not the same as cleaning the pipeline. When you hire, remaining live applications still need a terminal state. Leaving them in Interview as “backup” without a waitlist policy is how you ghost people and inflate WIP. Options:
- Reject with reason “role filled,” notify according to the rule.
- Move to a named waitlist or hold with a review date if you truly might reopen this requisition — not as a fake kindness.
- Invite strong people to a different open job as a new application, rather than silently recycling the old card.
Archive or close the job object so public portals and the internal board stop collecting applies you will not read. Applications already in the system still need their own closes. Deleting the job should not delete the history you need for audit. Archive; keep people.
The hiring checklist owns sourcing through offer as ops steps, including who may close a requisition. This article does not retell that ladder. It asks whether every application on that requisition has a terminal state when the live work ends.
What you are not doing on this page
You are not writing a discrimination policy. You are not interpreting POSH. You are not telling managers which interview questions are lawful. If a reject reason would look indefensible in a file, that is a prompt to talk to whoever owns employment relations in your company — not a prompt for this article to simulate counsel. Store reasons that map to the job and to evidence you actually collected. If you have no evidence, you should not have been at a decision stage; send them back to screen or record “incomplete.”
You are not AI-ranking rejects. A human chooses no. Dayzen recruitment’s pipeline records states; it does not rank applicants with a model. Volume at Applied is a reason to screen with a shared JD, not to invent a score that auto-closes people.
Failure modes
| Symptom | Missing piece | Repair |
|---|---|---|
| Interview column never shrinks | Terminal reject / withdraw | Ageing limit + owner who must close |
| Candidate emails “any update?” at month two | Date + communication rule | Close when decided; send or log no-send |
| Reason “not a culture fit” with empty notes | Evidence | File feedback or do not use that code |
| Same human banned from all jobs | Confused objects | Reject the application; keep the person |
| Job closed, portal still live, leftover cards | Requisition vs applications | Archive job; close each leftover row |
A close checklist on the application
- Confirm this is the right job and the right person — not a sibling application you still want live.
- Confirm evidence matches the stage (screen note or interview remarks).
- Select a reason code you would defend internally; add a short internal note if needed.
- Name the decision owner; stamp today’s date.
- Move to Rejected (or Withdrawn if that is the truth).
- Trigger or skip communication per the written rule, and record which happened.
- If this was the last live applicant because the role filled, confirm the job is closed or archived so new applies stop.
If step 2 is empty, you are not closing — you are hiding. Go get the note or admit you never screened. The stages article still owns what Interview means. The checklist still owns how you run the loop forward. Use this page when the argument is how a no becomes a file: terminal state, reason, owner, date, and a communication outcome you can point at. Keep it operational. Leave the law to people qualified to give it.
Related articles
Recruitment & Onboarding
Making the employee record payroll-ready at activation
Onboarding-to-payroll data contract. Not the payroll-run checklist and not automatic PF enrolment.
Dayzen
Recruitment & Onboarding
Common onboarding delays and how to prevent them
Failure-mode article. It does not replace the hire-to-activate pipeline explainer.
Dayzen
Recruitment & Onboarding
The hiring manager's onboarding responsibilities
Manager audience. The HR onboarding checklist remains HR-ops tasks. Dayzen does not provision laptops.
Dayzen
