Clean candidate data in a CSV
To clean candidate data, remove duplicate applicants by email, then split the full-name column into separate first and last name fields your ATS can map. Sigmera does both in your browser — candidate names and emails are never uploaded to a server, so applicant PII stays GDPR-safe by design.
Last updated: September 2026
Messy applicant lists slow down hiring
Candidates arrive from job boards, referrals, and your careers page, each in a slightly different shape. The same person applies to two roles and shows up twice. Names come in as one “Full Name” column, but your ATS wants first and last name separately and rejects the import or mangles the mapping. The result: duplicate candidate records, broken merge tags in your outreach (“Hi Jane Smith,” instead of “Hi Jane,”), and recruiters wasting time fixing data instead of talking to people. Cleaning the file first makes every downstream step — screening, scheduling, reporting — faster and less error-prone.
Step by step: clean your candidate list
- 1. Export your applicant list to CSV. Download it from your job board, spreadsheet, or ATS as one CSV file.
- 2. Remove duplicate applicants. Open the duplicate remover and match on the email column, ignoring case and spacing, so repeat applicants appear once.
- 3. Split the full-name column. Open the name splitter to break “Full Name” into first and last name fields your ATS can map.
- 4. Preview and download. Check the deduplicated, split result and download the clean CSV for import.
Before and after
| Raw applicant export | ATS-ready | |
|---|---|---|
| Name fields | “Jane Smith” (one column) | First: Jane · Last: Smith |
| Duplicate applicants | 2 rows, same email | 1 row (latest) |
| ATS import | Rejected / mis-mapped | Clean import |
| Outreach merge tags | “Hi Jane Smith,” | “Hi Jane,” |
🔒 Candidate data stays on your device. Both tools run in your browser’s memory — no file is uploaded, which keeps applicant PII GDPR-safe by design.
Cut the columns you do not need
A raw applicant export usually carries more than the hiring process uses. GDPR Article 5 requires personal data to be adequate, relevant and limited to what is necessary for the purpose it was collected for, and the same article sets a storage-limitation rule: data is kept in identifiable form no longer than that purpose needs. Trimming the file before the import is the cheapest moment to satisfy both.
- Keep the fields the ATS maps and the process depends on — name, contact details, the role applied for, application date, CV link.
- Drop columns a job board added but hiring never uses: date of birth, nationality, photo URL, and free-text notes written about a candidate rather than by them.
- Separate diversity-monitoring answers into their own file. They are special category data under GDPR and should not travel in the same sheet as the shortlist.
- Deduplicate before you delete. One row per candidate means one record to remove when the retention period ends, instead of three copies in three roles.
Removing a column is an edit like any other — the find and replace tool handles the value-level fixes in the columns you keep, and the wider pre-import cleaning checklist covers the order to work in. All of it happens in the browser, so a candidate list is never handed to a third party in the process.
A trimmed shortlist is also the version worth circulating. Once the file holds only the fields the hiring process needs, you can share it as a fixed PDF table rather than forwarding the spreadsheet — an interviewer gets a readable, paginated list instead of a file they can re-sort or edit, and the columns you deliberately dropped cannot reappear in a hidden sheet. The conversion runs in the browser, so the shortlist still never leaves your device.
When candidates arrive from more than one job board
Most recruitment data does not come from one place. LinkedIn, Indeed, your careers page, and a referral spreadsheet each export their own column names, their own date format, and their own idea of what a phone number looks like. Stacking those files is where an applicant list usually goes wrong, so do it in this order:
- 1. Align the headers before you stack. One board writes
Email Address, another writesemail. Rename them to match in each file first — stacking rows under mismatched headers is what silently drops a column later. - 2. Deduplicate after the merge, not before. A candidate who applied on two boards is only visible as a duplicate once both files sit in the same sheet. Match on email, ignoring case and spacing.
- 3. Standardize the phone column last. Formatting is cheaper on a deduplicated file than on three copies of the same candidate.
If you add a Source column while stacking, the merged file can also answer which board actually supplied the shortlist: chart the candidate count per job board by grouping on that column and summarizing with Count, after the deduplication so a candidate who applied twice is counted once.
Standardize candidate phone numbers for the ATS
Job boards collect phone numbers as free text, so one export can carry (415) 555-2671, +44 20 7946 0958, and 07700 900123 in the same column. An ATS that texts candidates, or any SMS gateway sitting behind it, expects the international E.164 form defined by ITU-T Recommendation E.164: a plus sign, the country calling code, the national number, up to 15 digits, nothing else. A number stored any other way either fails to send or matches no one.
The phone number cleaner converts a whole candidate column at once — you set the default country for numbers that arrive without a code — and what the E.164 format requires covers the rules if you would rather check the file by hand. Like the dedupe and name split, it runs in the browser, so candidate contact details never leave the machine you are working on.
Match the candidate file to your ATS template
Download your ATS's template before changing the file. Greenhouse's spreadsheet import uses separate First name, Last name, and Job fields; Workable also specifies header, email, and phone formatting. Follow the current instructions for Greenhouse or Workable rather than assuming that every ATS accepts the same layout.
- For a single Name column, separate first and last names and review compound surnames before mapping the columns.
- Trim and check the email column before matching duplicates. A personal and a work address can belong to the same candidate; exact email matching will not establish that identity.
- If the template expects one Location field, combine city and country under the required header.
- For an agency workbook, export the relevant sheet as CSV and check accented names in the preview.
Keep fields required for the import and remove unnecessary columns before the handoff. Working locally avoids sending the candidate file to a cleaning service; it does not replace your organization's rules for access, retention, or the later ATS upload.
When a candidate asks you to delete their data
GDPR Article 17 gives a candidate the right to have their personal data erased without undue delay once you no longer hold a lawful reason to keep it. An erasure request is far cheaper to answer on a file that carries one row per person. Three copies of the same applicant — one from a job-board export, one from an agency sheet, one in a spreadsheet someone saved to a laptop — are three places you have to find and delete, and the copy you miss is the one that reappears in next quarter's shortlist.
Deduplicating before the import is the cheapest version of that work. Collapse the applicant list on the email column so each candidate exists once, and note which system the export came from. Cleaning the file in the browser keeps the question smaller too: the copy you are editing never reaches a cleaning service, so there is no third-party copy to chase when a request arrives.
- Deduplicate first, so one candidate means one row to erase rather than several to hunt down.
- Delete the working CSV once the import is confirmed. An unmanaged copy in a downloads folder is still personal data you hold.
- Record the source of each export, so an erasure request can follow the data back to the system it came from instead of stopping at the ATS.
Frequently asked questions
- Why do I need to split candidate full names?
- Most applicant tracking systems store first name and last name as separate fields and reject or mis-map a single full-name column. Splitting names into first and last before import means candidates land in the right fields, so search, merge tags, and interview scheduling all work correctly.
- Is it safe to clean candidate data this way?
- Yes. Both the duplicate remover and the name splitter run entirely inside your web browser using client-side JavaScript. Candidate names, emails, and applications are never uploaded to a server and never leave your device, which is important for handling applicant PII and keeps the process GDPR-safe by design.
- How do I handle candidates who applied more than once?
- Deduplicate on the email column. A candidate who applies to two roles or reapplies will share the same email, so matching on email collapses them to one row. Keep the most recent copy to retain their latest application details, then review before importing.
- What about names with middle names or two surnames?
- The name splitter handles middle names with an optional middle-name field and treats the remaining words as the last name, so compound surnames like 'van der Berg' stay together. Always preview the split and fix any edge cases before downloading.
- Which columns should I drop from a candidate export?
- Drop anything the hiring process does not need. GDPR Article 5 requires personal data to be adequate, relevant, and limited to what is necessary for the purpose it was collected for, so a spreadsheet you are moving into an ATS should not carry date of birth, nationality, a photo, or free-text notes about a candidate unless the role genuinely requires them. Trim the columns before the import rather than after, because once the data is in the ATS it is far harder to account for.
- How long can I keep an unsuccessful candidate's data?
- Only as long as you have a purpose for it. GDPR Article 5 sets a storage-limitation principle: personal data must be kept in an identifiable form no longer than necessary. In practice, set a retention period for rejected applicants, write it down, and delete on schedule. Cleaning the file before import helps here too, because one deduplicated row per candidate means one record to delete rather than three scattered copies.
- Do I need a data processing agreement to clean a candidate list?
- Not for cleaning it in Sigmera, because there is no processor involved. A DPA is required when you send personal data to a third party that processes it on your behalf — which is what happens with an online cleaner that uploads your file. Sigmera runs the deduplication and name split in your browser's memory, so the candidate list never reaches a server and no third party ever holds it.
- How do I combine candidate lists from more than one job board?
- Rename the columns to match across every file before you stack the rows — one board exports 'Email Address' where another exports 'email', and stacking under mismatched headers is what quietly loses a column. Once the files are in one sheet, deduplicate on email, because a candidate who applied on two boards only shows up as a duplicate after the merge. Standardize the phone column last, when there is one row per person to format instead of three.
- Do I need to reformat candidate phone numbers before importing?
- If your ATS texts candidates or hands numbers to an SMS gateway, yes. Job boards store phone numbers as free text, so a single export can mix (415) 555-2671, +44 20 7946 0958, and 07700 900123. Gateways expect E.164 — a plus sign, country calling code, then the national number, 15 digits at most — and reject or fail to route anything else. Converting the column before the import is far easier than correcting individual candidate records afterwards.
- Can I catch a candidate who applied under two different email addresses?
- Not with exact matching alone. Deduplicating on email collapses the rows that share an address, which catches reapplications and the same candidate applying twice through one board. Someone who used a personal address on one job board and a work address on another will still appear as two rows. Sort the cleaned file by last name and read the adjacent rows before importing — the pairs stand out at that point, and merging two spreadsheet rows by hand takes less time than untangling two candidate records inside the ATS.
- What should I do with the CSV after the ATS import finishes?
- Delete it once the import is confirmed. The export sitting in a downloads folder is still personal data you hold, and it is the copy most likely to be missed when a retention deadline or an erasure request arrives. GDPR Article 5 limits how long personal data may be kept in an identifiable form, so a working file should not outlive the import it was made for. If you need it while you check the column mapping, keep one copy in a known location and remove it on a date you have written down.
Related use cases
- Deduplicate sales leads
- Clean a CSV before a HubSpot import
- Clean a customer list before a CRM import
- How to choose a data cleaning tool — candidate CVs are personal data, so where the file is processed matters.
- Splitting a full-name column in Excel — the Text to Columns, Flash Fill and TEXTBEFORE routes, and where each one breaks on a middle name.
- Tools used: remove duplicates, split full names.