Keeping office and mobile numbers on a HighLevel bulk import

How HighLevel stores more than one number

Each contact has room for up to 11 phone numbers. One of them is the primary. Each number can carry a label, from Mobile, Work, Home and Landline, and each label can be used once on a contact.

So one person can keep a desk line, a mobile and a home number on a single record. You don't need a second contact for the office line, and a second contact would split that person's history in two.

Why the office line ends up getting the texts

When nobody picks a primary on purpose, HighLevel uses the first number stored on the contact for outgoing communication. If the office line happened to land first, that's where texts and calls go.

Workflows follow the same rule: they use the primary number unless a step is set up to do something else. Keeping several numbers on a contact doesn't make a workflow try all of them. The extra numbers are there for your team to see and use, not for automation to work through.

The first number becomes the one HighLevel uses. Choose it on purpose.

Setting up the CSV

HighLevel's CSV format guide supports a separate column for additional phone numbers, comma-separated inside that column. An older troubleshooting page told people to split such contacts into several records instead. The newer guide wins, but HighLevel has changed this before, so check the current import screen before you build the file.

1. Decide which number should be primary for each contact. Put it in the main phone column.
2. Put every other number for that contact in the additional phone numbers column, separated by commas.
3. Keep the two columns distinct. Don't put the office and mobile numbers together in the main phone column.
4. During the import, map the main column to the phone field and the extra column to additional phone numbers.
5. Before the import updates existing contacts, review the sub-account's duplicate-contact settings, so the rows match the people you expect.

Loading through the API instead

If you load contacts with the upsert endpoint, matching follows the same duplicate-contact preferences set on the location. Review them first; they decide whether a row updates an existing person or creates a new one.

HighLevel's upsert documentation shows additionalPhones in the response, as objects with a phone and a phoneLabel. That tells you how HighLevel returns the numbers. It doesn't confirm what shape the request has to take, so don't build the request from the response example and assume it worked.

In our builds, some upsert payload shapes dropped the additional numbers without any error. A run whose access token expired partway through lost them too. The first of those gave no error at all, which is why the next step isn't optional.

Check a sample, then fix the record

After any bulk load, by CSV or API, open a handful of contacts and look before anyone starts calling.

1. Open a contact in Contacts and find Phone numbers.
2. Confirm every number from the source is there. If one is missing, add it with + Add Phone Number.
3. Give each number its own label, since a label can only be used once per contact.
4. Select Primary on the number that should get calls and texts.
5. Remove a wrong or duplicated number with the trash icon.
6. If the sample shows numbers missing across the board, stop and fix the file or the payload before loading the rest.