Your first import

This walks one small file all the way through, so you have seen every step once before you do it with data that matters.

Before you start

You need three things:

• The extension installed, and the Sloose tab open in your CRM. See Install for Zoho CRM.
• Discovery run at least once, so Sloose knows what modules and fields you have. An administrator does this once; if the modules list is empty, that is what is missing.
• A file with a header row. We will use a handful of accounts.

If you want to practise without touching your CRM at all, every screenshot below comes from the standalone sandbox, which writes to an in-memory destination and nothing else.

1. Home — choose what you are importing into

Pick the modules this file feeds. Most first imports are one module — start there; a row can create records in several modules and link them, but that is easier to reason about once the single-module case is familiar.

Give the job a name. It is optional, but it is what you will look for in your run history later, and “Monthly accounts” beats an untitled job from three weeks ago.

Then Start import →.

2. Data — load the file

Paste or upload. The file is parsed in your browser — nothing is uploaded to us to do it.

Sloose reads the delimiter automatically, and tells you what it found so you can overrule it if it guessed wrong. You get a row and column count, and a duplicate check across the file.

Two things worth doing here before you move on:

• Look at the duplicate notice. If the file repeats a row and you are creating records without matching, importing both writes the same record twice. Exclude the copy now — click the row’s exclude control — rather than cleaning it up in the CRM afterwards.
• Fix anything obviously wrong in the grid. Cells are editable. Your original file is not touched; the edit belongs to this job.

3. Match — decide what counts as the same record

This is the step that decides whether you end up with clean data or a pile of duplicates, and it comes before mapping on purpose: what the run is for shapes everything after it.

One decision per module. This file contains:

All new records	No matching. Every row creates.
Mix of new & existing	Match what exists, create what does not.
Updates to existing only	Match and update. Anything unmatched is left out.

Our sample is all new, so pick All new records — and read the warning it gives you, because it is the truthful one: import this file once, or you will create duplicates on the second run.

For the other two, you also say how a row finds its record: a field, a comparison, and a value from your data. Sloose shows you what that value actually looks like across your file — distinct values, blanks, errors — so you find out here, not at row 400, that the column you chose is empty half the time.

More on this in Match records.

4. Map fields — connect columns to fields

Auto-map makes the first pass. It is deliberately conservative: it proposes what it is confident about and leaves the rest to you, because a wrong mapping that looks right is worse than an obvious gap.

Each proposal says where it came from. “your org calls it this” means an administrator has recorded that your files use that name for that field — see Field annotations.

Then finish the rest by hand. The footer counts what is mapped and flags required fields still empty; you cannot leave the step with a required field unmapped.

A field can take a column, a fixed value, a formula, or a live search against another module.

5. Values — translate what the file says into what the CRM expects

Your file says Tech. The picklist says Technology. This is where you say they are the same thing.

Anything unmapped is listed. You can map each value, or deliberately leave a value blank — which is a real answer, and better than inventing a category to park it in.

6. Validate — see every problem before anything is written

Problems are grouped by where you fix them, not by where they were found, each with a link back to that step.

Errors block the run. Warnings do not. A warning is Sloose telling you something you may not have intended — a field that will import empty on 40 rows, say — and letting you decide.

Where there is a one-click way through, it is offered. Our sample’s unmapped picklist values have one: Leave 4 values blank.

7. Import — the run

Do the dry run first. It goes through every row and every rule without writing anything, so you see what would happen while it is still free to be wrong.

Then Import. Rows are written one at a time with a live log. You can pause and cancel, and the header shows what happens on an error and on several matches — both of which you can change before you start.

8. Results

Every row, what happened to it, and why. Filter to errors, click a row to see exactly what was sent and what came back.

If some rows failed and others succeeded, that is a normal outcome, not a broken run: fix the failures and retry just those.

Then, if this is something you will do again — Save it as a project. Next month the mappings, match rule and value maps are already there and you only bring a new file. See Save and reuse a project.

The two things people get wrong first time

Importing before discovery has run. If the field you want is not in the list, the CRM’s schema has not been read since it was added. An administrator runs discovery again and it appears.

Matching on a field that is not unique. Matching on company name looks fine on the sample and falls apart on the real file, where two branches share a name. Match on something that identifies one record — an account number, an email address — and if there is no such field, consider whether this file is really an update at all.