Run the import

Dry run first

A dry run goes through every row and every rule — matching, formulas, value maps, validation — and writes nothing.

What it proves: your formulas run against real data, your match rule finds the records it should, your value maps cover the values in this file, and the row count is what you expected.

What it does not prove: that the CRM will accept every record. Field-level rules on the destination — a validation rule, a mandatory field Sloose was not told about, a workflow that rejects something — only show up on a real write.

A dry run never pauses and never stops on an error, whatever the settings below say.

Do it anyway. Most problems are the kind a dry run catches, and it costs nothing.

Authorisation, and why a run that starts always finishes

Before writing anything, Sloose asks the server for permission for this many rows. That check happens once, at the start.

The consequence is the useful part: your allowance cannot run out half way through. Either the run is refused before it writes a single record, or it has the allowance it needs and completes. There is no state where a thousand rows are in and the rest are locked out.

A set bigger than your plan allows in one import is refused with LIMIT_ROWS_PER_RUN before anything is written — narrow the row range or split the file. When the period’s import runs are used up, a real run is refused with LIMIT_RUNS; dry runs still work. A run counts when it writes its first row, so a dry run or a cancelled run costs nothing. See Plans and limits.

If a record fails

What a real run does when the CRM rejects a record:

Ask me	Pause on each failure and show you what happened. Good for a first run of an unfamiliar file.
Skip row	Record the error, abandon the whole row, continue.
Skip record	Skip only the record that failed — the row’s other records still import.
Stop run	Stop everything at the first failure.

Skip row and Skip record differ only when a row writes to several modules. If a contact fails but its account succeeded, Skip record keeps the account and Skip row still keeps it — the account was already written — but stops trying the rest of that row.

For a file you have run before, Skip row and a look at the failures afterwards is usually the right shape.

When several match

A match rule that finds more than one record is ambiguous. One match never asks; several is a decision:

Ask me	Pause and show the candidates.
Use first	Take the first without asking.
Skip	Leave that record untouched.
Create new	Create a new record anyway.

Use first is a trap on a rule you have not verified — “first” is whatever the CRM’s search returned, which is not a promise about which record it is. If you are seeing several matches often, the rule needs to be narrower; see Match records.

While it runs

Rows are written one at a time, with a live log. You can pause and cancel.

Writes are paced — there is a minimum gap between them, set per org, so a large import does not trip your CRM’s rate limits. An administrator can adjust it under organisation settings; the default is deliberate and you should have a reason before shortening it.

Resuming

If a run stops part way, Sloose offers to resume at the next row after the last success. That sets the start row, so the rows already written are not written again.

Worth knowing what this does and does not do: it is a row cursor, not a transaction. Records already written stay written.

Retrying failures

After a run with errors, Retry n failed re-runs just the rows that failed, with whatever you have fixed in the meantime.

This is the normal shape of a real import: run, fix a handful, retry. Rows that succeeded are not touched.

What is recorded

Every run — dry or real — writes a row to your org’s history: who started it, how many rows, what happened, which modules. That history is retained for as long as your plan says, and shows up under Results and history.

Your data is not recorded. The history says what happened, not what was in the file.