Referrals 2.0: “referral already exists” When Resubmitting a Prospect to a Different Campaign

Solution / Supported Workarounds

Observed error

“referral already exists”

Option 1 — Mark the original referral as invalid/wrong campaign (recommended for reporting clarity)

1. Open the Referrals 2.0 admin area (Admin Referral Dashboard / referral management view).
2. Locate the affected referral (use identifiers available in your admin UI such as prospect email, referral name, created date, etc.).
3. Transition the referral to a Lost-type milestone or a custom milestone that clearly indicates it should be treated as invalid, for example:
   • Invalid
   • Submitted to wrong campaign
   • Test / duplicate
4. Save the change.
5. Update internal reporting filters/exclusions so this milestone is handled appropriately (for example, excluded from “valid pipeline” reporting).

Option 2 — Manually award the correct incentive to the advocate

If the business intent is “the advocate should receive the incentive as if the referral were submitted under the correct campaign,” use a manual award:

1. When the deal meets the incentive criteria for the intended campaign, use your hub/admin rewards tooling to manually grant the equivalent points or reward to the advocate.
2. Document internally that the manual award corresponds to the referral that was submitted under the wrong campaign (to preserve auditability).

Option 3 (Optional) — Submit using an email alias if acceptable

If your email policies and recordkeeping allow, submit a new referral in the correct campaign using an email alias that routes to the same mailbox but is treated as a different string by Referrals 2.0 (for example, plus addressing):

• Example pattern: <local_part>+<tag>@<domain>

Notes:

• This only works if the prospect’s email system supports aliases/plus addressing and your organization accepts the altered email value for tracking.
• Treat this as optional; it may not be appropriate for all programs.

Platform Limitations (What Cannot Be Done)

Referrals 2.0 enforces a uniqueness constraint on the prospect email. Once a referral exists for a given prospect email, that email cannot be used again for a new referral submission—even if the original referral is later transitioned to a Lost status.

Referrals 2.0 does not provide a supported mechanism (UI or API) to:

• Delete an existing referral
• Change the referred prospect’s email on an existing referral
• Move/reassign a referral from one campaign to another

What will not work

• Marking the referral as Lost and attempting to resubmit the same <prospect_email> to another campaign (the duplicate constraint still applies).
• Requesting deletion, campaign reassignment, or prospect email edits through standard UI/API (not supported in Referrals 2.0).

Backend Edit Evaluation (Not Performed)

A one-off backend/database update (delete/update prospect email) was evaluated with the infrastructure team. The change was not executed because there is no documented/tested process (runbook) to safely modify referral records at the database level, and performing an ad hoc edit could introduce data inconsistencies. As a result, no backend changes were made.