Import contacts

Prepare the file#

The unit is a person, not an address. A human with a work address, a personal address and a mobile number is one row with three identity columns, not three rows — because that is how the record model works, and an import that fights it produces duplicates you then have to merge.

• One row per person. Company goes in a column; organisations are records in their own right and several people attach to one.
• Separate columns per identity. An address is one identity on one channel; a phone number is another. Keep them apart rather than combining them into a single contact field.
• No invented addresses. If you do not have a real address for somebody, leave it empty. Connect does not pattern-generate one, and a guessed address in the file becomes a real send attempt to a stranger.
• Plain values. CSV, TSV and XLSX are all read. Merged cells, multi-row headers and totals rows are the three things that most often turn a clean list into a confusing mapping screen.

Import it#

1. Start the import from the sheet that matches what you are bringing in — people if these are relationships, prospects if they are research leads you have not contacted.

   Result The destination decides which fields exist to map to, and which gates the rows will pass through afterwards.

2. Map your columns to fields, and read the mapping rather than accepting the guess. A column called contact could be a name, an address or a phone number, and the guess has to pick one.

   Result Every column is either mapped deliberately or excluded deliberately.

3. Import a small slice first — twenty rows, not two thousand.

   Result You find a wrong mapping while it costs twenty records to undo instead of an afternoon of merges.

4. Check the imported slice against the file by opening two or three records, including one you know is already a customer.

   Result This is the verification. Identity resolution should have attached the known person to their existing record rather than creating a second one beside it.

5. Run the rest, then open the duplicates view.

   Result Anything the import could not resolve confidently is proposed as a duplicate for a person to decide, which is the designed outcome rather than a failure.

What happens to each row#

That last row is worth dwelling on. Importing a list does not grant permission to write to it. Anyone the workspace has previously suppressed stays suppressed, and the compliance check runs before outreach regardless of how the record arrived.

After the import#

Two checks are worth ten minutes. First, counts: compare the number of rows in your file with the number of new records created, and account for the difference — matched people explain most of it, duplicates and identity-less rows explain the rest. Second, one merge: work through the proposed duplicates rather than leaving them, because a merge preserves identities, lifecycle stages, follow-ups, deals, demos, cases and onboarding from both sides, and the longer two half-records both accumulate history the more there is to reconcile.

Everything imported as new people

The identity columns were probably not mapped as identities, so nothing could match. Merging is the repair; remapping and re-importing on top is not.

Names look wrong or truncated

Check the file's encoding before blaming the import. A spreadsheet that guessed at import time is the usual culprit.

Records exist but nothing is contactable

The address column was empty or unmapped. This is the case where the no-guessed-address rule shows: the records are real research, and their next action is finding a real address rather than trying a likely one.

The list was for one campaign and is now permanent

It is. An import creates records, not a temporary list, and removing them later is a separate decision.

Questions#

Related#

• Uploading your own list
• Relationships in Connect
• Clean up duplicate records
• Export your data
• Connect does not guess email addresses
• Telling a new prospect from an existing customer