Applicant

How does an applicant differ from a candidate in record terms?

A candidate is a position in a process; an applicant is an event that happened against a numbered opening on a specific date. Every applicant is a candidate, and plenty of candidates are never applicants because they were sourced, assessed and declined without submitting anything. Day to day the difference is invisible and nobody misses it. It becomes decisive the moment someone has to reconstruct who was formally considered for a role, which is exactly when the informal version of the record turns out to be missing.

What belongs in an applicant flow record?

Enough for a stranger to reconstruct the decision years later without having been present. That means the opening identifier, the date and time of submission, the artefacts submitted, the coded outcome and the plain reason behind it, the person who made the call, and the point in the process at which it was made. Self-identification data is normally held separately with restricted access so it cannot inform the decision it is meant to help audit. The test is reconstruction, not tidiness.

Why is the definition contested at all?

Because regulators, software vendors and internal reporting each draw the boundary somewhere slightly different. Some definitions require that the person expressed interest in a specific position and met the stated basic qualifications through the employer's chosen intake. Others count every submission received. Neither is universally correct and the applicable test varies by jurisdiction. The practical obligation is to choose one, write it down, apply it consistently, and repeat it wherever the resulting number is published so readers know what they are looking at.

What separates a formal application from an expression of interest?

An application is a dated submission made against an identified opening, using whatever intake the employer defined for it. An expression of interest is everything else: a CV emailed to a recruiter, a talent community sign-up, a business card handed over at a conference, a note asking to be kept in mind. Interest creates a person record. Only the submission creates the formal artefact that reporting and any audit will later be built on.

Employers should publish which artefacts count and route every genuine interest in a live opening through the same intake. Otherwise a hiring manager's inbox operates as an undocumented parallel channel, the counted pool diverges from the real one, and nobody can reconstruct afterwards who was considered. The fix is procedural rather than technical: one door per opening, and a habit of walking people to it.

Why is a sourced person sometimes asked to apply?

Because the formal artefact only exists once the submission does. Where an employer carries applicant flow reporting duties, a person who was approached, assessed and turned down without ever submitting anything may fall outside the reported set, or may fall inside it under a broader test. The definitions differ by country and can differ by regulator inside one country, so the question belongs with counsel rather than with a recruiter's judgement.

Practically, many employers ask a sourced person to complete a short submission before any formal interview, so that consent language, the invitation to self-identify where applicable, and the link to a specific opening all sit on one dated record. Handled clumsily this reads as pointless bureaucracy. Handled well it is one brief step, explained honestly as record-keeping rather than dressed up as a hurdle. The explanation matters more than the form does.

How does a loose applicant count corrupt recruiting metrics?

Several ratios rest on this denominator, and none of them announce when it moves. Cost per applicant, submission completion, screen rate and interview ratios all shift the moment a bulk import, a duplicate submission or an abandoned draft is admitted to the count. Nothing real changed; the numbers moved anyway, and the team spends the next review arguing about a variance that exists entirely inside the definition.

The typical drift is optimistic. Counting starts rather than completed submissions inflates the top, and treating each submission from a repeat applicant as a separate person inflates it again. Decide whether the unit is submissions or people, encode the choice in the reporting layer rather than a footnote, and label every chart with the unit it used so nobody has to guess. The unit is a decision, not a formatting detail.

How should repeat applicants across openings be handled?

One person, several submissions. The system should link them under a single person record so a reviewer can see the history, while the reporting layer retains the ability to count either people or submissions on demand. Never merge the submissions themselves: each one is a dated artefact tied to a specific opening, and collapsing them destroys exactly the record that a later audit would ask to see.

There is a fairness consequence as well. A reviewer who can see three previous rejections may carry that impression into an assessment for a different role with different requirements. Some employers surface the existence of earlier submissions but withhold the earlier coded outcomes until the current decision is recorded, which preserves the audit trail without letting a stale verdict decide a new one. The earlier record stays intact either way.

How long should application records be kept?

Set a period for each category of record, tie each period to a documented reason, and make deletion actually fire rather than sit in a policy document. Some jurisdictions impose minimum retention on recruitment records while simultaneously granting individuals erasure rights, and the two pull in opposite directions. Resolve that tension with local advice instead of picking whichever rule is easier to implement, because the easier rule is the one you will eventually have to defend.

Write the schedule at the artefact level: the submission form, the CV, interview notes, assessment output, and any self-identification data, which is normally stored apart from the decision file with separate access. Then have the system enforce it. A retention policy nobody can execute inside the software is a liability dressed as a control, because it documents an obligation the employer is visibly failing to meet.