Two LinkedIn Conversation Exports Swapped Prospect-to-Thread Links: Restore Both Subjects

A prospect-to-thread link swap has one narrow repair: restore the two correct associations and leave the messages alone. The failure is not that either export is incomplete. It is that two intact threads point to the wrong prospect records.

Start by freezing the two exports and the two prospect records, then freezing every downstream action that reads the link. Then build a two-row ledger. The ledger makes the reciprocal pattern visible, records why each corrected edge is justified, and gives a reviewer one place to sign off.

LinkedIn's download guidance says Messages data can include the date sent or received along with a subject line; it can also include content and the member's public profile URL. Use only fields actually present in the two exports. Do not fill gaps with a guessed identity or a remembered conversation.

• Keep the original export files read-only.
• Record the export IDs and prospect IDs before changing links.
• Pause downstream use of the two records until the reviewer signs off.

How do you prove which prospect belongs to each intact export?

Build the proof from fields that identify the conversation itself. Start with the export ID, then compare the subject line and the member public profile URL, then compare dates and message sequence where those fields exist. A subject line alone may be enough for a clean pair. If it is ambiguous, keep the repair on hold.

The aim is to establish two positive matches, not one plausible match and one leftover. Prospect A must have direct evidence for thread A. Prospect B must have direct evidence for thread B. The observed links should then show the inverse arrangement.

Do not use activity outside the export to manufacture certainty. LinkedIn's privacy policy states that communications through its services can indicate who members communicate with and when. That makes message records sensitive operational evidence. Limit access to the repair reviewers and avoid copying message content into the ledger when IDs and selected fields will do.

• Compare the prospect record's known public-profile URL with the URL in each export, if both are present.
• Compare the subject line and message chronology without changing either export.
• Record the evidence field and its value for both positive matches.
• Stop if the evidence supports only one pairing or conflicts across fields.

What should the two-export permutation ledger contain?

Use a compact ledger with one row per prospect. The expected edge is the prospect-to-thread relationship supported by the intact export. The observed edge is the incorrect relationship currently stored downstream. The correction should change only that association.

The labels below are a template. Replace them with the actual export IDs and prospect IDs. Keep the original observed edge in the record so a later reviewer can see that the repair was a reciprocal swap rather than a new classification.

How do you repair a reciprocal subject-edge swap without rewriting messages?

Apply the repair as two explicit association updates in the same controlled change. First set Prospect A to Thread A. Then set Prospect B to Thread B. Do not delete the old threads, edit subjects, duplicate messages, or infer a third record.

Before releasing the records, query the two resulting edges and compare them against the approved ledger. The expected result is exactly two corrected associations, with message counts, timestamps, subjects, and export IDs unchanged.

If the system cannot update the two associations without altering conversation data, stop. Export records, message records, and derived links are different things. A tool limitation is not a reason to recreate message history.

• Capture the pre-change observed edges.
• Apply only the two approved association updates.
• Re-read both records after the update.
• Confirm the export IDs and message counts did not change; confirm the subject fields did not change.
• Attach the reviewer approval and change timestamp to the ledger.

When should you hold the repair instead of forcing a match?

Hold the repair when either export lacks enough evidence to tie it to one prospect. Also hold when the two exports contain conflicting identifiers or another record could reasonably fit either thread. A clean reciprocal pattern does not make an uncertain subject assignment safe.

LinkedIn says members can request specific data categories through its download process, and the available categories depend on the account and activity. If an export is missing a field, describe it as missing. Do not treat its absence as proof that the other prospect owns the thread.

For a consent-based outreach workflow, keep the repair focused on accurate routing and review. Do not use the incident as a reason to share accounts, bypass platform controls, or expand access to conversation data.

• Hold when a profile URL or subject points to different prospects, or when chronology does.
• Hold when the export cannot establish both positive matches.
• Hold when a downstream automation may send a message before the corrected edge is independently verified.

Why keep provenance with the correction?

The repair needs a record of what changed, why it changed, and who approved it. W3C's PROV data model describes provenance as information about the entities and activities involved in producing or delivering data, along with the people involved. A small repair ledger applies that idea without turning a two-record fix into a larger migration.

Keep the source export IDs, original edges, corrected edges, evidence fields, repair timestamp, reviewer, and verification result together. The next reviewer should be able to recertify the two links without reading private message content unless the evidence review requires it.