What your contact file needs before it can be mailed

Most exports come out of practice or field-service software with forty columns and no obvious way to tell which ones matter. Only a handful do. Everything below is what the importer actually checks — not a wish list.

1. Give every row a name — any one of four will do

   A row needs one of: a first name, a last name, a full name, or a company name. That is genuinely the whole rule. Practices and trades often hold records under a business name with no personal name attached, so a company name on its own is enough to address a card. If your export has separate first and last columns, leave them separate — the importer handles both shapes.

2. Give every row a complete address — all four parts

   Here the rule is stricter, because the post office is strict: a row needs a street line, a city, a state, and a ZIP. All four. A row missing any one of them cannot be addressed and will not import as mailable. A second address line — apartment, suite, unit — is optional, and is carried through when present.

3. Leave the headers alone

   You do not need to rename anything to match a template. The importer recognises the header names these systems already emit — FirstName, fname, PatientFirstName, Address1, MailingStreet, StreetAddress, Zip, PostalCode, MailingZipCode and dozens more, in any capitalisation. Anything it cannot place, it shows you in the mapping step so you can point it at the right field by hand.

4. Keep the record id if your export has one

   If the file carries the id your software uses internally — Open Dental's PatNum, a Dentrix chart number, an Eaglesoft patient id, an account or member number — keep the column. CardCadence stores it against the contact, which is what lets you re-export later and match people back up rather than guessing from names that may be spelled differently in each system.

5. Export as CSV and import it

   Save as CSV, upload it, and check the mapping screen before you commit. It shows what each column was matched to and flags columns it detected but could not place — worth a glance, because a phone column quietly left unmapped is easier to fix now than after the cards are printed.

What is optional, and worth having anyway

Email and phone are never required to mail a postcard, and a card will go out perfectly well without them. They are worth including anyway: they give you a second way to reach the people who respond, and they make it possible to recognise the same person across two different exports.

What happens to rows that are missing something

Rows without a usable name or without a complete address are not silently dropped into your mailing — the importer separates them so you can see what came through and what did not. Fixing a handful of incomplete rows in a spreadsheet is usually faster than re-running the export with different settings.