Some imported rows are missing
A row that does not arrive was refused, matched or never became a candidate, and the import report tells you which. Refused rows failed the owning service's validation. Matched rows updated a record you already had rather than creating a second one. Rows that never became candidates were blank, headerless or outside the mapped columns. Nothing is discarded quietly.
Read the report before re-importing#
The instinct after a short import is to run it again with a different setting. That is nearly always the wrong move: the second run meets the same rules and produces the same shortfall, and now there are two imports to reason about. The report from the first run already contains the answer.
| Outcome | What it means | Where it shows |
|---|---|---|
| Refused | The owning service would not accept the record | Listed with a reason per row |
| Matched | The row updated an existing record instead of creating one | Counted as an update, not as an arrival |
| Not a candidate | Blank, partial, or nothing in the mapped columns | Counted against the file, not against the sheet |
| Arrived | A new record exists | The count you were expecting to match the file |
Add the four together and you should get the number of data rows in the file. When they do not add up, the file itself is the place to look: a trailing blank block, a second header partway down, or a sheet in the workbook that is not the one you meant.
The three causes, and what each looks like#
- Validation refused the record
- Usually one column doing it repeatedly — a date in a format the service will not take, a required field left empty, an identifier that is not one. Group the refusals by reason and you will normally see two or three shapes covering everything.
- Matching turned a row into an update
- Not a loss at all. An address or a number already on file makes the row that person or that company, which is what stops an import doubling your relationships. The record changed; the count of new records did not.
- The row never became a candidate
- Blank rows, rows where every mapped column is empty, and rows below a second header. These are counted honestly rather than treated as errors, because a spreadsheet almost always has some.
What Connect completed#
- Every row was examined. There is no early exit: a refusal at row 40 does not stop row 41 from being tried.
- Records that passed were created or updated through their owning service, with the same validation any other route uses.
- A per-row account exists, which is what makes the arithmetic above possible.
- Provenance was kept. The file is stored, so a record can be traced back to the row it came from.
What Connect did not complete#
Refused rows were not queued, parked or half-created. There is no partial record waiting for a missing field, and nothing will arrive later without you importing it again. A row that was refused is simply not there.
Connect also did not correct the file for you. A date column in an ambiguous format is not reinterpreted, a name is not split into first and last on your behalf, and an address that looks like a typo is not repaired — because a guess written into a record is indistinguishable from a fact a month later.
Fixing it in one pass#
Sort the refusals by reason and fix the file column by column.
Result Two or three edits in a spreadsheet usually clear most of the refused rows at once.
Leave the matched rows alone.
Result They are already applied. Re-importing them is harmless but pointless — setting a field to what it already holds is a no-op.
Delete blank and stray-header rows from the file rather than filtering them in the interface.
Result The next report's arithmetic becomes readable, which is what you want if a second shortfall appears.
Import the corrected file again and compare the two reports.
Result The difference is the evidence that your fix worked, and it takes seconds compared with checking records one by one.
An administrator can widen the permissions that caused an access refusal and can change a rule that a whole column is failing against. Neither an administrator nor the Connect Assistant can force a record past its own service's validation, so a persistently refused column is a signal about the data rather than a lock to be opened.
Escalate when the four counts do not reconcile against a file you have checked, or when rows reported as arrived cannot be found on the sheet. Both point at something other than the data, and the useful details are the sheet, the row count and the report's own totals.
Questions#
Is a matched row a lost row?
No — it is the feature working. A row that matched an existing person or company updated that record instead of creating a duplicate, which is why an import into a workspace that already has relationships almost never produces as many new records as the file has lines. Check the update count before treating the gap as a fault.
Can I see which existing record a row matched?
The duplicates view shows pairs the matcher was not confident enough to merge, and a record's own timeline shows the change the import made to it. Between those two you can establish what a given row did, though the fastest check for a specific contact is usually to open that contact.
Why were rows refused that a spreadsheet accepted happily?
A spreadsheet accepts anything in a cell; a record has fields with meanings. A date column that holds three different formats is fine in a spreadsheet and is three different problems to a service that has to store one date. The refusal is the point at which that difference becomes visible.