ORCID Auto-Update Not Working: Fix It

ORCID’s auto-update feature is supposed to mean a researcher never has to manually add a new article or dataset to their ORCID record: once Crossref or DataCite deposits a DOI that includes the researcher’s ORCID iD, the record is meant to update itself. When that doesn’t happen, it’s rarely a single obvious bug — it’s usually one link in a three-party chain (publisher/repository, Crossref or DataCite, and the researcher’s own ORCID settings) that never got connected in the first place. This guide walks through that chain in the order most likely to actually find the problem, using ORCID’s, Crossref’s, and DataCite’s own documentation of how the mechanism is supposed to work.

How ORCID auto-update from Crossref and DataCite is supposed to work

Auto-update is not a single ORCID feature — it’s a coordinated process across three parties, and all three steps have to succeed for a record to update itself:

The researcher authorizes a trusted organization. In their ORCID record, under Works, the researcher connects to “Crossref Metadata Search” (for journal articles and other Crossref-registered content) and/or DataCite (for datasets and other DataCite-registered outputs) as a trusted party and authorizes ongoing updates. This appears afterward on the researcher’s ORCID record permissions / Trusted Parties page, where it can also be revoked at any time.

A publisher or repository submits the researcher’s ORCID iD in the deposit. When an article or dataset is registered for a DOI, the metadata sent to Crossref or DataCite has to include the author’s ORCID iD — not just their name. This depends entirely on the submitting publisher or repository actually collecting and forwarding it; ORCID itself has no way to add an iD to a deposit it never received. CASRAI’s Crossref metadata deposit workflow guide covers what publishers are expected to submit and when.

Crossref or DataCite notifies ORCID, and the researcher approves the addition. When a new DOI carrying a trusted researcher’s ORCID iD is registered, Crossref sends an update request to that researcher’s ORCID inbox and registered email. The researcher (or, once trust is established, ORCID processing on their behalf) has to accept the notification for the work to actually land on the record — archiving or ignoring it does not add the work.

Works added this way carry a visible marker (a check-mark style source icon) distinguishing them from self-asserted entries, which is one quick way to confirm whether a given item was added automatically versus by hand.

Step-by-step diagnostic checklist

Work through these in order — most “auto-update isn’t working” reports trace back to the first three steps, not to an actual Crossref/DataCite-side fault.

1. Confirm the trusted-party permission was actually granted (and is still active)

Sign in to ORCID, open the record, and check the Trusted Parties / Works permissions section. “Crossref Metadata Search” and/or DataCite should be listed as an active trusted organization. If it isn’t listed at all, auto-update was never turned on — connecting it is done from Works > Add > “Import works from other services,” selecting Crossref Metadata Search or DataCite, and authorizing access. If it was listed previously and is now gone, permission was revoked (either by the researcher directly, or, in the case of DataCite/Crossref connections tied to a since-deauthorized session) and has to be re-granted.

2. Check for a stuck or declined notification before assuming nothing happened

This is the single most common false alarm: auto-update isn’t a silent background sync for Crossref-sourced works. A new deposit generates a notification in the researcher’s ORCID inbox and email requesting approval; if that notification was archived, deleted, or simply missed in an inbox, the work never gets added even though permission is otherwise correctly configured. Check the ORCID inbox and the account’s registered email (including spam/junk folders) for a Crossref update-request message before concluding the connection itself is broken.

3. Confirm the researcher’s ORCID iD was actually present in the deposit

Auto-update matches on the ORCID iD field in the deposited metadata, not on the author’s name. If a manuscript or dataset was submitted without the ORCID iD entered at the submission stage — a common gap when a journal’s submission system makes the ORCID field optional, or a co-author’s name was added without linking their iD — Crossref or DataCite has nothing to match against, and no notification is ever generated. This is a submission-time problem, not something fixable after the fact from the ORCID side; it typically has to be corrected by the publisher amending the deposit, or simply won’t be corrected for that specific record.

4. Check whether the publisher or repository submits ORCID iDs at all

Not every publisher or repository collects and forwards ORCID iDs in its Crossref or DataCite deposits, even now. Smaller or older journal platforms in particular may register DOIs without any author-identifier metadata. If a researcher has never seen auto-update work for a given venue and step 3 rules out a one-off missing entry, check that venue’s typical DOI registration practice — some publishers simply don’t include ORCID in their metadata pipeline yet, in which case there is nothing on the researcher’s or ORCID’s side to fix.

5. Rule out a timing delay before troubleshooting further

Auto-update is triggered by DOI registration events, not by publication date, and processing isn’t instantaneous. A newly published article can take some time to appear as a Crossref or DataCite deposit and generate the corresponding ORCID notification. Before treating a missing work as a genuine failure, confirm the DOI itself has actually been registered (searchable via Crossref’s or DataCite’s own search tools) — if the DOI isn’t live yet, auto-update has nothing to act on regardless of how correctly everything else is configured.

6. Check the works visibility default — the item may have been added but hidden

Works added by a trusted organization inherit the researcher’s configured default visibility for that source (public, trusted-parties-only, or private) under ORCID account settings. A work can be successfully auto-added and still look “missing” if the researcher’s default visibility for trusted-party additions is set to private or limited — it’s on the record, just not showing in the view being checked. Reviewing the record while signed in, with visibility set to show all items regardless of privacy level, rules this out.

7. Confirm which ORCID account is actually connected

Researchers who registered more than one ORCID iD over the years (common when a duplicate is created at a new institution or under a slightly different name) sometimes have the wrong one connected to their publisher submissions, or check a different iD than the one actually granted trusted-party access. CASRAI’s guide on how to register, find, and search for ORCID iDs covers how to check for and consolidate duplicate iDs.

8. When it genuinely looks like a Crossref- or DataCite-side issue

After ruling out steps 1–7, a small number of cases are documented as genuine platform-side gaps rather than researcher error — for example, DataCite’s own public issue tracker has recorded cases where DOI records carrying a correctly embedded ORCID iD were not forwarded to the corresponding ORCID record despite auto-update being properly enabled on the researcher’s end. These appear to be uncommon rather than systemic, but they’re a real, documented failure mode distinct from misconfiguration, and are worth ruling in only after the more common causes above have been checked and eliminated.

Crossref vs. DataCite auto-update: what differs

The two run on the same underlying trusted-party model but cover different content and are connected separately in ORCID’s Works settings:

Crossref auto-update applies to Crossref-registered DOIs — primarily journal articles and other publisher-registered scholarly content. It is the more heavily documented and widely used of the two, since journal article metadata is where ORCID iD collection at submission is now standard practice across many major publishing platforms.

DataCite auto-update applies to DataCite-registered DOIs — chiefly research datasets, software, and other non-article outputs deposited through data repositories. Because ORCID iD collection is less uniformly enforced across the wider range of smaller and institutional data repositories that register DOIs through DataCite, gaps at step 3 or step 4 above (ORCID iD missing from the deposit, or not collected at all) are, anecdotally, more likely on the DataCite side than the Crossref side.

Each is a separate connection under Trusted Parties — enabling one does not enable the other, so a researcher who authorized Crossref years ago but never connected DataCite (or vice versa) will see auto-update work for one content type and not the other, which is often mistaken for a broken feature rather than a missing second authorization.

If none of this resolves it

Once the ORCID-side configuration, the metadata, and timing have all been checked and the problem persists for a specific, identifiable DOI, the remaining escalation paths are: ORCID’s own support team (via the help contact form linked from support.orcid.org), Crossref support for a Crossref-registered DOI, DataCite support for a DataCite-registered DOI, or the publisher/repository directly if the issue is that ORCID iDs are missing from their metadata pipeline entirely — that last case is a publisher-side fix, not something ORCID, Crossref, or DataCite can resolve after the fact for records already deposited without it.

Frequently asked questions

Does revoking and re-granting trusted-party access fix a stuck connection?

It can, for connections that appear active but stopped generating notifications — revoking access under Trusted Parties and reconnecting via Works > Add > Import works from other services re-establishes the authorization cleanly. It won’t fix a case where the underlying deposit never contained the researcher’s ORCID iD in the first place, since there’s nothing for a fresh connection to match against retroactively.

Will auto-update add older publications retroactively?

Only if a corresponding DOI deposit already carries the researcher’s ORCID iD and a matching trusted-party connection is active when that deposit is processed or reprocessed. Auto-update responds to registration/update events at Crossref or DataCite; it is not a one-time bulk import of a researcher’s back catalog, which is a different, manual process (searching and importing works directly).

Why does it work for journal articles but not for a dataset I deposited?

Most often because only the Crossref connection was authorized and DataCite was never separately connected under Trusted Parties, or because the data repository used to register the dataset’s DOI doesn’t collect ORCID iDs in its DataCite deposit — see the Crossref-vs-DataCite differences above.

Is auto-update the same thing as the ORCID/Scopus or ORCID/Google Scholar connection?

No. Crossref and DataCite auto-update is a permission-and-metadata-matching mechanism specific to DOI registration. It’s a different integration from linking a Scopus Author ID (see CASRAI’s guide on linking a Scopus Author ID to ORCID) or manually adding Google Scholar publications, which rely on different matching logic entirely.

For the broader picture of how ORCID fits alongside DOIs, ROR, and institutional identifiers, see CASRAI’s identifier crosswalk guide. For how a comparable auto-import/export relationship works inside a CRIS platform rather than directly from Crossref/DataCite, see Pure and ORCID: how auto-import/export actually works.