Importing your contacts

An import in Consonas runs in two halves: a first pass that reads your file and writes nothing at all, and an approval that writes everything. Almost every decision worth making belongs to the half before either of them.

It is far easier to fix a file than to fix four hundred records. Everything in this section is a spreadsheet task and all of it is quicker before the import than after.

Decide what not to bring

This is the most important thing on this page and it is the one most often skipped. The instinct is to import everything, because the data feels free and might be useful one day.

What that produces is a system where a search for a common surname returns four plausible records and nobody knows which is current, where marketing lists are full of addresses that bounce, and where the number of contacts tells you nothing about the business. Filter to the people and organisations someone in your team would recognise. You can always import the rest later, and in practice almost nobody ever wants to.

Fix the telephone numbers

Spreadsheets treat telephone numbers as numbers and remove the leading zero. This happens before the file reaches us and nothing downstream can recover it. Format the column as text, or put an apostrophe before each number, and check a few by eye.

One email address per cell

A cell containing two addresses separated by a semicolon or a slash cannot be interpreted safely, so the row is skipped and reported rather than guessed at. Decide which address is the right one, or split the row.

Make the dates consistent

A column where some rows are written one way and some another usually means someone edited the file on a different computer. The rows that cannot be read are skipped and listed, which is fine, but it is quicker to make the column consistent first.

Check the columns actually contain what they say

Sort by each column and look at the top and the bottom. This takes two minutes and it is how you find the eleven rows where a company name ended up in the surname column, which is the single most common fault in a real file.

1. Upload the file

Nothing is written at this point. The product reads the file, works out what the columns contain, and suggests a mapping.

A comma separated file is what to bring, and the reason that format travels between systems at all is that somebody wrote its shape down as RFC 4180 long after everyone had already agreed on it. Import, export and search covers what the same machinery does once your records are in.

2. Correct the mapping

Check every column, including the ones it guessed correctly. Columns you do not map are ignored rather than silently discarded, and the preview lists them so you can see what you are leaving behind.

If your file contains people and their employers, map both. The import creates the organisation and connects the person to it, which is the shape you want and the one that would otherwise take two passes and manual work.

3. Read the preview properly

This is the step that matters and the one people rush. It tells you how many records will be created, how many existing ones will be updated, and how many rows will be skipped and why.

Read the skips first. They are where your file disagrees with itself, and they are frequently the most informative thing you will learn about data you have been carrying for years. Then check a handful of the creates by eye: are the names in the right fields, did the company come through, is the type right.

4. Cancel if anything looks wrong

Because nothing has been written, cancelling costs nothing. Fix the file and upload it again. Doing this twice is normal and doing it three times is not a failure, it is the process working.

5. Approve

Records are created. From this point they exist, so this is the moment the preview was protecting you from.

6. Spot check, then export

Open five records and read them. Then run an export, which is free and takes seconds, so you have a copy of the state immediately after the import and you know the export works.

Search for your ten most important customers

By name, by email address, by telephone number. This finds two things quickly: records that did not come through as you expected, and duplicates that existed in your old system without anybody knowing.

Merge the duplicates you find

Merging keeps both timelines, both sets of files and both sets of connections, and the merge itself is recorded. Do it while the number is small. Duplicates multiply, because each one becomes a plausible destination for future work.

Do not add custom fields yet

Wait a fortnight. The fields you would add today are mostly inherited from the system you are leaving, and about half of them will never be filled in twice. After two weeks of real use you will know which two or three genuinely change what somebody does.

Import the second file, if there is one

If your history is spread across several spreadsheets, bring them in one at a time and read each preview. The second import will match against records created by the first and update rather than duplicate them, which is the behaviour you want and the reason to do them in sequence instead of combining the files by hand.

Most rows describe two things

A person, and the organisation they work for. That is two relationships and a connection between them, not one record, and importing it as one produces a system that cannot answer who else works there or what happened when that person moved.

The preview shows you what it made of each row before anything is written, which is exactly the moment to check this. Look at five rows and ask whether what was created is what you meant.

Sometimes the durable thing is neither

In several trades the record that lasts is not a person or a company. It is a site, a property, a household, a case or a party, and the people around it change.

If that is true of your trade, decide it before importing rather than afterwards. The sector pages each carry a modelling section saying what the durable record is for that trade and how to represent it below the Enterprise plan.

Connections are where the value is, and they are easy to skip

A connection carries a role and usually a period. Someone is a director of one company until March and of another from April, and both stay true of their own dates.

An import that creates records without connections produces a list. An import that creates connections produces something that can answer a question. The extra work is one column, and relationships and connections explains what the connection is then able to answer.

Bring consent with its provenance or not at all

A column marked yes is a tick rather than a consent record. Consent here is a fact with a date, a source and a channel, and importing a tick as consent carries an assertion you may not be able to support. The Information Commissioner's Office is the place to read what has to be demonstrable, and campaigns and consent records describes how the product checks it at the moment of sending.

If you have the date and the source, bring them. If you do not, knowing that before somebody sends a campaign is considerably better than knowing it afterwards.

A hundred rows first, always

Then open five of them at random. Almost every problem shows up in the first hundred, and undoing a hundred is a completely different proposition from undoing four thousand.

Two questions worth asking of every column

What did a person actually type into this, and what would somebody do differently if it were wrong? The first question catches the column that says email and contains a mixture of addresses and the word none. The second decides whether the column is worth carrying at all, which is usually the more valuable answer.

Column headings survive far longer than the reasons for them. A file that has moved through three systems in a decade often carries a heading nobody in the building can explain, still faithfully populated, because each migration mapped it to something rather than making a decision about it.

Translation is where meaning goes quietly

Nothing announces itself when a column is mapped to a field that is nearly right. The import completes, the records look plausible, and eighteen months later somebody asks a question the data cannot answer because the answer was flattened into a text field during an afternoon nobody remembers.

This is the whole reason the mapping step is separate from the upload and the preview is separate from both. Splitting them costs you two clicks and buys you the only opportunity to notice a translation before it becomes a fact.

There is no connector to the system you are leaving

You export a file and you upload it. A connector sounds better and quietly means something else: two systems writing to the same records, a reconciliation problem no one owns, and a migration with no moment when it finished.

A file has a date on it. Somebody chose what was in it and someone approved the preview, and in a year the question of what came from where has an answer. The cost is genuinely yours: if your current supplier makes exporting difficult, that is an obstacle we can neither remove nor help with, and it is worth finding out how difficult before you commit to anything.

Nothing is filled in from anywhere else

Some systems will complete the gaps in your file from third party sources: a telephone number here, a job title there, a company size no one asked for. We do not, and would not.

Data you did not collect arrives with no provenance you can describe. The first time someone asks where a telephone number came from, or a person exercises their rights over it, the answer needs to be a sentence about your own relationship with them instead of a shrug about an appended dataset. Your gaps stay gaps, which is the honest version of what you actually know.

Nothing is sent to anyone because a row arrived

Importing a file contacts nobody in it. No welcome message, no notification, no sequence beginning on its own. That is deliberate, because the moment an import can send email is the moment a mistake in a spreadsheet reaches four hundred people and cannot be recalled.

The consequence is that whatever you want said to the people you have imported is a thing you compose and send deliberately, after you have looked at what you actually imported.

There is no repeating import on a schedule

An import is an event you approve, so a recurring one would be a synchronisation with a nightly cadence and the same two writer problem as a connector, minus the person reading the preview.

If a file genuinely has to arrive from another system every night, that is an integration question instead of an import one and it is worth raising before you buy rather than after. We would rather tell you that a different product suits you than have you discover it in month three.

Your old system's history stays your old system's history

Your records come across. The record of who changed what in the system you are leaving does not, because writing those entries here would stamp our provenance on events that happened somewhere else, and an audit trail that says a thing happened here when it did not is worse than no entry at all.

This is a real reason to keep the old export rather than cancelling the old account and deleting everything the same week. Whatever obligation you had to be able to explain what happened in the old system is an obligation that outlives the subscription.