Bringing leads into a list, whether by import or by harvest, now ends with a breakdown rather than a total. You see what was added, what was already yours, and what was refused, with the reason for each refusal.
What changed
The old result was a number. Two hundred and forty leads added. That number is true and it is not enough, because the interesting question is almost always about the ones that are missing rather than the ones that arrived.
If you uploaded a file of three hundred and two hundred and forty went in, the sixty that did not were unexplained. They could have been duplicates of contacts you already had, which is fine. They could have been rows with a missing email address, which is a problem with the file. They could have failed validation, which is a problem with the data. Each of those calls for a completely different response, and the number gave you no way to tell which you were looking at.
The result now separates them. Added, duplicate, and rejected, with rejections grouped by reason. A file with forty rows missing an email address and twenty invalid addresses says exactly that, so you know to fix the export from wherever the file came from rather than hunting through three hundred rows by hand.
How to use it
Import a file or run a harvest as you normally would. The breakdown appears when it finishes.
Read the rejected group first, because it is the only one that indicates something wrong. Duplicates are the system protecting you and added is the work succeeding. Rejections are the part that might mean your source needs attention.
Where rejections cluster on one reason, fix that reason at the source and re-import. A file where a hundred rows failed for a missing email is a file exported without an email column, and re-exporting takes less time than repairing the rows.
Why it matters
An unexplained gap between what you uploaded and what arrived is the kind of thing that quietly erodes confidence in a tool. You did not do anything wrong, the number is smaller than expected, and there is nothing to read that explains it. The natural conclusion is that something is broken.
Usually nothing is broken. Most of the gap is duplicates, which is the system doing precisely what you want. But without the breakdown, correct behaviour and a genuine data problem produce the same experience, and both feel like a fault.
There is a practical benefit too. Data problems at the source repeat. A CRM export that drops email addresses will drop them again next month, and knowing that from the first import is what stops it becoming a monthly annoyance.
The rejection reasons
Missing email. The row had no address, so there is nothing to send to. This is by far the most common and it is almost always an export problem rather than a data problem.
Invalid address. The address is present but cannot be valid, usually a typo or a placeholder that made it into a real system.
Suppressed. The address is on your suppression list, having bounced, complained, or unsubscribed previously. Rejecting these protects your domain, and the rejection is the system working properly.
Failed validation. The record is missing something required beyond the address, or a field contains something that cannot be right.
Duplicates deserve reading too
A duplicate count that is high relative to what you imported tells you something useful about the segment rather than about the file.
If you import three hundred prospects and two hundred are already contacts, you have covered this segment much more thoroughly than you thought. That is worth knowing before you build a campaign around it, because the hundred genuinely new prospects may not justify the campaign you were planning.
Duplicates are matched on email address, so the same person at a new company arrives as a new lead rather than being skipped. That is the right behaviour, since a job change is exactly the moment worth reaching out.
Fixing a file rather than a list
When rejections cluster, the fix belongs upstream. Repairing rows inside the product means doing it again next time, while fixing the export means it stops happening.
The most common upstream fix is including the right column. Exports from CRMs frequently default to a subset of fields that does not include a work email, and nothing about the export warns you.
The second most common is encoding. A file saved in the wrong character encoding turns accented names into nonsense, which does not reject the row but does put bad data into your greeting line.
Suppressed addresses are not a mistake
Of the four rejection reasons, suppression is the one people query most, because it feels like the product is refusing to do what it was asked.
It is. An address lands on your suppression list because it bounced, because somebody complained about a message from you, or because somebody unsubscribed. Sending to any of those again damages your sending domain, and in the case of an unsubscribe it is not something you should be doing regardless of what it costs.
The suppression list is per workspace and viewable, so an address you believe is there in error can be checked rather than guessed at.
Where this shows up
The breakdown appears at the end of a file import, at the end of a harvest, and on the harvest result card in Chat.
It also persists on the list, so a list assembled last month still carries the record of how it was built. That matters when a campaign underperforms and you are trying to work out whether the list or the writing was the problem.
Exporting a list exports the leads that made it in, not the rejected rows. Where you need to repair rejected rows, the source file is the place to do it.
Availability
Live now on all plans, for file imports, harvests, and leads added through Chat.