GoHighLevel Import Contacts: A Step-by-Step CSV Guide

The GoHighLevel import contacts tool only behaves if your CSV file matches its formatting rules before you click upload.

Get the file wrong, and the platform won't reject it outright. It just skips columns it can't match, and you often won't notice until a workflow fails weeks later.

Admin access is required to run an import at all.

The file must be a genuine .csv, not a renamed Excel workbook, and tops out at roughly 30 MB on one sheet. Every row needs a first name, email, or phone number for the system to treat it as real.

GoHighLevel Import Contacts: What the CSV Needs First

A header row is mandatory, and it can't be blank. Each column name has to match an existing standard field or a custom field you've already built, since the import won't create one on the fly.

Formatting inside the columns matters as much as the headers above them.

GoHighLevel's CSV format rules expect a specific shape for dates, phone numbers, tags, and multi-select fields. Getting one wrong is a common way for a column to come in empty.

Country and timezone values must match GoHighLevel's supported lists exactly, case included, or they fail silently.

Mapping Columns Without Losing Data

Once the file's uploaded, you choose whether you're adding new contacts or updating existing ones, then work through a field-mapping screen. A green check mark next to a column means it's matched.

Anything left unmapped gets ignored rather than dumped into the wrong field, though a typo in your header row can quietly cost you a whole column of data.

Custom fields have to exist in the account before the import runs. If your spreadsheet has a column with no home in GoHighLevel, building that field properly first takes less time than re-running a failed import.

When you're updating existing contacts rather than creating new ones, turning on "Don't update Empty Values" stops a blank cell from wiping out data already in the CRM.

Agencies running a client's first GoHighLevel setup and configuration tend to flip that setting by default, since a half-populated spreadsheet is the norm.

Where Duplicate Contacts Actually Come From

GoHighLevel checks for an existing match in a fixed order: Contact ID first, then email, then phone. That order is adjustable through the account's deduplication preferences.

Most duplicate headaches trace back to a CSV that never matched cleanly, not a setting that needed changing. A short list of mistakes causes most of the failed rows:

• Headers that don't match any field name, even by one character
• Required fields left blank on some rows but not others
• Phone numbers carrying stray punctuation the system won't parse
• The same contact appearing twice within the same file

The import's "Show Stats" screen breaks out how many rows succeeded and which failed, so you don't have to guess.

Contacts arriving this messily usually mean the account's structure wasn't settled before the migration, the exact problem a GoHighLevel CRM setup built around structure first is meant to prevent.

Letting Business Names Build Company Records

If your CSV includes a column named exactly "Business Name," GoHighLevel can turn that into something more than a text field.

Once switched on under Settings, Objects, Companies, the platform reads that value on each contact and creates or links a matching company record, marking it primary. It works retroactively too, sweeping in contacts that already have a business name on file.

One limit is worth knowing first. According to GoHighLevel's documentation on the feature, companies can't be imported as their own standalone object; the only path in runs through a contact import carrying that column.

Building that association into a broader workflow automation setup afterward beats restructuring a CSV to fake it.

Cover photo by Jan van der Wolf on Pexels