How Applicant Tracking Systems Actually Work

Overview

An applicant tracking system is a database with a workflow attached. That is the whole of it, and understanding how applicant tracking systems work mostly means understanding which parts of hiring the database can represent and which parts it cannot. A great deal of folklore has grown up around these systems — that they auto-reject on keyword density, that particular fonts defeat them, that a hidden white-text keyword block gets a CV through. Most of it describes software behaviour that either never existed or stopped existing a decade ago.

This is written for both sides. If you are choosing a system, it tells you where the real work sits. If you are applying through one, it tells you what is actually being read.

1. Parsing turns a document into fields; parsing quality, not keyword tricks, is what decides how a CV is represented.
2. Filtering is configured by a recruiter, not decided by the software.
3. The workflow is the point — most of an ATS's value is coordination, not evaluation.

What happens between upload and shortlist

Intake. An application arrives from a careers page, a job board, a referral link, or a recruiter uploading a CV directly. The system creates a candidate record and attaches the document, the source, and the role applied for. Source tracking sounds administrative and is one of the more useful things an ATS does: it is how you learn which channels produce hires rather than volume.

Parsing. The system extracts text from the file — PDF, DOCX, sometimes DOC — and attempts to map it into structured fields: name, contact details, employment history with dates and titles, education, and skills. This is where CV formatting genuinely matters, and where the folklore has the mechanism half right and the conclusion wrong. Complex multi-column layouts, tables, text embedded in images, and headers that a parser reads out of order produce garbled fields. A garbled field is not a rejection; it is a record that reads badly to the human who opens it and that will not match a structured search. The practical advice for candidates is unglamorous: single column, standard section headings, real text rather than a graphic, a common file format.

Deduplication. Most systems check whether the person already exists, usually by email. Applicants reapplying across roles are merged into one record with an application history rather than scattered across duplicates.

Screening. Knock-out questions on the application form — work authorisation, notice period, a required certification — can filter automatically, because the answers are structured and unambiguous. Beyond that, filtering is typically a recruiter running searches and applying criteria, not the system making independent decisions.

Pipeline. The candidate moves through configured stages: screen, interview, assessment, offer. Each move triggers whatever the workflow specifies — a task, a notification, a template email. This is where an ATS earns most of its keep.

What do applicant tracking systems look for?

Less than the internet suggests, and differently. What a modern system supports is structured search and ranking over parsed fields: titles, dates, employers, education, skills, and answers to application questions. A recruiter searching for candidates with a specific certification and three years in a domain is querying fields, not scanning prose.

Where scoring exists, it is typically a relevance score against a role's stated requirements, presented as an ordering to a human rather than as a verdict. It moves a candidate up a list. It does not send a rejection.

Three points of folklore worth retiring. Keyword stuffing generally does not help, because ranking is comparative and a wall of terms without corresponding roles and dates reads as noise to the parser and worse to the recruiter who opens the file. Hidden white text is visible to a parser precisely because the parser reads text and ignores colour — it is a straightforward way to have your application discarded by a person. And exotic fonts are irrelevant unless the document is an image; what breaks parsing is layout, not typeface.

The honest summary is that an ATS decides how legible you are, and a human decides everything else.

1. What an ATS does well:
   • Keeps one record per candidate with a complete application and communication history.
   • Makes a pipeline visible — how many people are at each stage, and how long they have been there.
   • Sends the templated communications that otherwise get forgotten, including the rejections.
   • Records source, so you can tell which channels produce hires rather than applications.
2. What it does not do:
   • Judge whether someone is good at the job. Structured scoring compares stated evidence against stated requirements; it does not assess capability.
   • Fix a badly written role definition. Vague requirements produce vague ranking.
   • Remove bias. It can standardise a process, which helps, and it can also encode a preference consistently, which does not.
   • Carry the hire past the offer, unless onboarding is part of the same system.

Where the ATS stops

The most common operational gap is the offer. The ATS knows a candidate reached the offer stage and then, in a lot of organisations, the process falls out of the system entirely: contracts by email, right-to-work checks in a shared drive, equipment requests in a chat thread, and a start date that HR learns about when the person arrives. The candidate experiences this as a fortnight of silence between the best conversation they have had with your company and their first day.

Closing that gap is why hiring and onboarding increasingly sit in the same platform. In our suite, Hirepacket covers positions and applicants, structured resume scoring, LinkedIn job posting, and onboarding packets — per-hire completion steppers with employee Q&A and bulk import — so the accepted candidate keeps moving instead of being re-keyed into the next tool. From there the record continues into Cadence HR as an employee rather than starting again. The broader argument for keeping adjacent processes on one record is in our piece on where administrative overhead actually accumulates.

If you are choosing a system

Test parsing with your own CVs, not the vendor's samples — take twenty real applications from your last search and see how the fields come out. Ask which job boards you can post to and whether that is included. Check whether stages, forms, and scorecards are configurable per role, since an engineering hire and a warehouse hire are not the same pipeline. Confirm what candidate-facing communication the system sends and whether you control the templates and the sender address. And ask about export early: candidate data is the asset, and moving it is either straightforward or effectively impossible.

If you are an agency rather than an employer, the requirements diverge sharply — many clients, shared candidate pools, and a fee and placement layer that corporate systems do not model. We covered those checks in what recruitment agencies should check in a private-label ATS.

Where to go next

If the record after the hire is the part you are missing, our explainer on what an HRIS is and when a growing company needs one picks up exactly where this article stops. To see the hiring and onboarding side working on one record, look at Hirepacket or the HR teams view of the suite. Ask for a walkthrough on your own roles — we would rather show it than describe it.