# 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.

- **Status:** Available
- **Audience:** both
- **In the app:** #/prospects, #/relationships, #/companies
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/prospect-already-customer/

## 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

1. 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.
2. 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.
3. 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.
4. 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.

> **Note** Escalate when a candidate resolves to a relationship that shares no address, no domain and no similar name with it. None of the four signals explains that, and it is worth reporting with both records named.

## 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.

## Related

- [Resolving a prospect to an existing relationship](https://connectbyjbrh.com/docs/prospects/prospect-identity/)
- [Identities](https://connectbyjbrh.com/docs/relationships/identities/)
- [Telling a new prospect from an existing customer](https://connectbyjbrh.com/research/prospect-identity-resolution/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Importing a prospect list, end to end](https://connectbyjbrh.com/docs/workflows/list-import/)
- [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §4 and §5 — identity resolution and merge behaviour
- `docs-source/sources/GENERAL.md` §1 and §2 — workspace isolation
- `backend/app/prospect_identity_resolution.py`, `backend/app/identity.py`
- Connect capability registry (`docs-source/facts.py`)