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.

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

Remove duplicate applicants Split full names

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.

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 writes email. 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.

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.

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.

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.