What the removal tool actually does
Two things are often confused here: moving information between records and removing a duplicate. ORCID’s duplicate-removal process is the second. It does not merge publications, employment history, peer-review credits or connected permissions from one record into the other.
ORCID’s duplicate-removal process transfers email addresses but not the duplicate record’s other information or permissions. Source
That single sentence drives most of the preparation. Anything on the duplicate other than its email addresses should be treated as at risk unless you move it yourself beforehand. Whether a given item type can be re-added to the surviving record, and how, is something to confirm in the ORCID interface rather than assume.
The removed duplicate cannot be reinstated; its persistent iD points to the primary record. Source
The permanence is the reason for a worksheet. If the wrong record is removed, there is no undo button to fall back on.
Decide which iD survives before you touch anything
You are choosing between two identifiers you own. Neither choice is universally correct, so work from evidence rather than habit.
| Question | Favours keeping this record | Favours removing this record |
|---|---|---|
| Which iD appears in published papers, datasets or grant records? | Most external citations resolve here | Few or no outside citations |
| Which record holds the fuller history (works, affiliations, reviews)? | Contains records you would otherwise rebuild | Mostly empty or outdated |
| Which email address do you still control and expect to keep? | Address is current | Address is defunct |
| Which iD is linked to other services you rely on? | Active connections you want to preserve | Connections you no longer use |
Editorial advice, not an ORCID rule: when the two records are close, let external citations decide. The surviving iD keeps its own identity; the other becomes a pointer. Choosing the one already embedded in your publication record usually costs less cleanup later.
The preserve-and-confirm worksheet
Fill this in for both records before you sign in to either one. Keep it somewhere you can return to, because the removal is one-way.
Record A (candidate to keep)
- iD:
- Email addresses currently on the record:
- Works listed (count and any you would not want to lose):
- Affiliations and employment entries:
- Peer-review or service credits:
- Connected external services and permissions:
- Places this iD is cited (journal pages, datasets, grant systems, institutional profiles, personal site, email signature, CV):
Record B (candidate to remove)
- Same fields as above.
- Items that exist only here and would need to be re-added to Record A first:
- External references that point to this iD:
Confirmation step
- For every external reference to the record being removed, note whether it can be updated, whether it will simply redirect, or whether it will break. You do not need to fix all of them before removal, but you should know which ones exist.
- Confirm you can still sign in to Record A with an email address you control.
Running the removal
The operation is performed from the record you are keeping.
The owner signs in to the record to keep and uses Account actions, Remove a duplicate record with the duplicate’s credentials. Source
In practice: sign in to the record you decided to keep, open the account actions area, and choose the duplicate-removal option. The tool then asks for the credentials of the duplicate — meaning you need working access to both records, not just the survivor. If you cannot sign in to the duplicate, the removal cannot proceed as described, and you should resolve access first rather than create further records.
Failure paths to plan for
- You cannot access the duplicate. The flow depends on the duplicate’s credentials. Recover access to that account before starting; do not open a third record as a workaround.
- The duplicate holds unique works or affiliations. Move or recreate them on the surviving record first. Removal will not carry them across.
- Connected services point at the duplicate. Those permissions do not transfer. Plan to reconnect the services you still use to the surviving iD afterwards.
- You picked the wrong survivor. There is no reinstatement path. This is the step to slow down on.
- External systems still cite the old iD. Expect to update profile pages and submission systems where you can, and to rely on the pointer behaviour where you cannot.
After removal: confirm, then tidy
- Sign in to the surviving record and check that your email addresses are present.
- Re-add any works, affiliations or credits you deliberately set aside, and confirm they display as expected.
- Reconnect external services you still use.
- Open a few of the external references you listed and note what they now show.
- Keep the worksheet until every reference has been checked at least once.
If the same name or handle appears across several services and you want a fuller picture of where it is used before you update profiles, the walkthrough on finding accounts linked to a name is a reasonable next step. Treat what it surfaces as leads to check, not as confirmation that a given profile belongs to you or anyone else.
Where TraceSeek fits, and where it does not
TraceSeek is a username search app covering 3,000+ platforms, with a free first scan that takes roughly 20–30 seconds according to the product. It can help you notice where a handle appears publicly. It does not manage ORCID records, perform duplicate removal, or prove that a profile belongs to a particular person. ORCID’s own account tools are the only place to carry out the steps above.