Connect refused to prospect an existing customer
The candidate resolved to a Person or Company already in your relationships, so it was not created as a cold prospect. That is prospect_identity_resolution doing the job it exists for. When the match is genuinely wrong, the fix is to correct the identity that caused it rather than to disable the check.
What it looks like#
A company you expected on the list is not there, or an import summary reports rows as customer matches, or a manual attempt to create a prospect is refused with the existing relationship shown instead. All three are the same event described from different screens.
No error is raised, because this is a successful outcome in most cases. The match and its reason are on the decision trail — a refusal is a decision, and the trail is where a run that returned fewer rows than expected is usually explained.
What the match was made on#
| Signal | Correct when | Wrong when |
|---|---|---|
| An address already held as an Identity | It is genuinely the same address | The address was attached to the wrong Person earlier |
| A shared web domain | The organisations are the same | A group domain covers several independent businesses |
| Organisation name plus location | The name is distinctive locally | Two unrelated businesses share a common name in one town |
| A person's name | It is unusual | Common names, or a namesake at a different company |
The lower two rows are where false matches come from, and both are consequences of the same trade-off: a check strict enough never to match wrongly would also let a real customer through, which is the failure that actually costs something.
What Connect completed and what it did not#
- Completed: the candidate was researched far enough to be resolvable, and the resolution was recorded with its reason.
- Completed: the existing relationship is shown, so the useful response — a call, a renewal, a conversation with whoever owns the account — is reachable rather than hidden.
- Not completed: no prospect record was created, and no research beyond resolution was paid for.
- Not completed: nothing was sent, and no sequence was started against either the candidate or the matched relationship.
- Not completed: nothing was merged or altered on the existing Person or Company. A match is a refusal to create, not an edit.
Correcting a wrong match#
Open the relationship that was matched and read its identities.
Result A false match nearly always has a wrong Identity behind it — an address attached to the wrong Person, or a domain on a record that should not carry it.
Correct the identity at its source.
Result Resolution is a consequence of the identity data, so correcting the data fixes every future run as well as this one.
If the two records genuinely describe one organisation, merge them.
Result The merge preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides, and future resolution then has one target rather than two.
Create the prospect again, or re-import the row.
Result With the identity corrected, the candidate no longer resolves and proceeds to research as normal.
An administrator can additionally check whether the workspace holds stale identities — addresses attached to people who left, or a domain recorded against a group rather than a subsidiary. Those produce recurring false matches that look like a fault in prospecting and are not.
Questions#
Can I force this candidate through as a prospect?
Correcting the identity is the supported route, and it is usually a thirty-second edit. There is no per-candidate override, because an override leaves the wrong identity in place to cause the same match again next month.
Does this mean my customer will never be researched?
It means they will not be prospected. Everything you know about them lives on the relationship, which is the richer record — it carries the actual correspondence rather than what a public source says.
Could a match come from another workspace's data?
No. Resolution runs inside one workspace and cannot see another's, and that is enforced by the allowlist, the workspace kernel and row-level security independently rather than by a setting.