How ORCID Auto-Imports CRediT Roles

When a journal tags each author’s CRediT contributor role during submission, that role information can flow automatically into the author’s ORCID record without the researcher typing anything into ORCID directly. This page covers specifically how that pipeline works: the metadata path from publisher to Crossref to ORCID, what has to be true for it to fire, and which part of the process is publisher-dependent rather than universal. It assumes you already know what CRediT and ORCID are individually — for general background on either, see the CRediT & Authorship Attribution pillar and the ORCID iD dictionary entry linked above.

The two-hop pipeline: manuscript submission to ORCID record

CRediT roles do not travel from a journal’s peer-review system straight into ORCID. They pass through an intermediate registration step:

At submission or production, the journal’s manuscript system (or the publisher’s production workflow) collects each contributor’s CRediT role assignment — commonly one or more of the taxonomy’s 14 roles, such as Conceptualization, Investigation, or Writing – Original Draft.
At registration, when the publisher deposits the article’s metadata with Crossref to mint or register its DOI, that deposit can include the tagged contributor roles alongside each contributor’s ORCID iD, if the researcher supplied one and the publisher’s deposit includes it.
At auto-update, ORCID’s auto-update service picks up new Crossref (or DataCite, for non-article outputs) deposits that reference a known ORCID iD. If the researcher has granted the relevant source auto-update permission, the work is added to their record — and if the deposited metadata carried CRediT role values, those roles are written in alongside it.

Every step in that chain is a separate dependency. A missing ORCID iD at submission, a publisher deposit that doesn’t carry role data, or a researcher who never granted auto-update permission each independently breaks the automation at a different point — which is why “my roles didn’t show up in ORCID” can have several unrelated causes. See Why ORCID Auto-Update Isn’t Working for a diagnostic walkthrough.

The technical mechanism: ORCID’s contributor-role field

ORCID’s Works record schema has long supported a contributor-role field listing what each named contributor did. In April 2021, with the release of ORCID API 3.0, ORCID added native support for the CRediT taxonomy’s 14 defined roles as accepted values for that field, alongside its own pre-existing, broader contributor-role vocabulary. A single work entry can list multiple contributors, each with one or more role values, and a role can be shared by more than one co-author (see How Many CRediT Roles Can One Author Hold, and Can a Role Be Shared? for the mechanics of that specifically).

The role value itself is a URI pointing at the canonical CRediT vocabulary rather than free text — which is what lets ORCID, Crossref, and downstream systems like CRIS platforms all interpret “Formal analysis” the same way regardless of which system wrote it. That vocabulary’s home changed in 2022: CRediT was stewarded by CASRAI from its 2014 publication until it became the ANSI-accredited standard ANSI/NISO Z39.104-2022, at which point ongoing maintenance of the taxonomy — including its canonical role identifiers — moved to NISO. Integrations built or documented before that transition may still reference the earlier CASRAI-hosted identifiers; current guidance points to NISO’s own hosted vocabulary as the canonical source.

The publisher side: Crossref deposit schema 5.5

The mechanism only works if the publisher’s deposit actually carries the role data in the first place. Crossref’s metadata deposit schema version 5.5 added native support for CRediT inside its existing contributors element: a contributor can be tagged with multiple roles, a degree-of-contribution qualifier (lead, equal, or supporting), and a corresponding-author flag, all alongside their ORCID iD. CASRAI has a dedicated technical implementation reference for this exact deposit-side markup — see Crossref Schema 5.5 & CRediT Contributor Roles for the XML structure and namespace details; this page focuses on what happens after that deposit reaches ORCID, not on how to author the deposit itself.

Not every publisher’s production system implements this yet, and adoption is publisher- and even journal-specific rather than industry-wide. By the time ORCID’s own API added CRediT support in 2021, NISO reported CRediT itself was already standard practice at more than 30 publishers — but using CRediT in a contributions statement and depositing that data in a form Crossref and ORCID can machine-read are two different levels of implementation, and only the latter enables automatic import.

What the researcher has to do

Auto-import is opt-in on the researcher’s side, not automatic the moment a publisher supports it. Three things have to be true:

The researcher needs an ORCID iD and must supply it during manuscript submission — an iD added after publication won’t retroactively trigger import for that work.
The researcher must grant auto-update permission to the relevant source — usually via a one-time consent flow, often prompted by an email notification when a new work referencing their iD first appears. This is a long-lasting grant (ORCID’s own guidance describes it as good for up to 20 years or until the researcher revokes it), not a per-article approval.
The publisher’s deposit has to actually be tagged with role data, per the section above — this part is entirely outside the researcher’s control.

See ORCID record permissions for how ORCID’s broader public/trusted-party/private visibility model works, and ORCID work assertion for the distinction between a work a researcher added themselves and one asserted onto their record by a trusted source such as a publisher via the ORCID API.

Why this matters

Two things follow from a role being written by a publisher via the API rather than typed in by the researcher. First, it removes a manual step: a researcher with auto-update enabled does not need to revisit ORCID after every publication to keep their contribution record current. Second, and more consequentially, it changes how the data is trusted downstream. ORCID records track the source of every entry, not just its content — a role asserted by a publisher (a “trusted organization” acting through the ORCID Member API) is recorded differently from one a researcher self-enters, and institutions, funders, and CRIS systems that read ORCID records generally weight source-asserted data more heavily, precisely because it did not pass through the individual it credits. That matters increasingly as ORCID data feeds directly into funder-facing documents — see How to Link ORCID to SciENcv for NIH Biosketches for one concrete example of ORCID-sourced data flowing onward into a formal funding document.

Limitations to know about

No automatic backfill. A work published before the publisher’s system supported CRediT deposit, or before the researcher granted auto-update permission, will not retroactively gain role data just because the researcher enables the connection later. It can typically only be added or corrected manually, or reimported if the publisher issues a corrected deposit.
DOI-dependent. The pipeline runs through Crossref (or DataCite) DOI registration. Outputs without a DOI — some conference papers, older items, certain book chapters — fall outside this specific mechanism entirely, regardless of whether CRediT roles were assigned to them elsewhere.
Self-entry is a different, lower-trust path. A researcher can always add or edit contributor role information on their own ORCID works manually, but that entry is recorded as researcher-asserted, not source-asserted — it doesn’t carry the same provenance signal as data written by the publisher via the Member API.
Not every system in a researcher’s workflow supports this the same way. Research information management systems that sync with ORCID, such as Elsevier’s Pure, run their own import/export logic layered on top of (not identical to) the base ORCID auto-update mechanism — see Pure and ORCID: How Auto-Import/Export Actually Works if your institution uses a CRIS platform rather than relying on ORCID directly.

Frequently asked questions

Does every journal automatically send CRediT roles to ORCID?

No. It depends on whether the publisher’s production system tags CRediT roles in its Crossref deposit (schema 5.5 or later) in the first place, and separately on whether the researcher has granted auto-update permission. Neither condition is universal across publishers yet.

Do I need to do anything for my CRediT roles to appear in ORCID?

Yes. You need an ORCID iD supplied at submission time and a standing auto-update permission granted to the depositing source (typically accepted via an email prompt the first time a new work referencing your iD appears). Without both, the role data can exist in the publisher’s deposit without ever reaching your record.

Can I add my CRediT roles to ORCID myself if the automatic import doesn’t happen?

Yes, manually editing a work entry is always available, but it’s recorded as self-asserted rather than publisher-asserted data, which downstream systems may weight differently.

Does this same mechanism work for datasets and other non-article outputs?

The auto-update mechanism itself extends to any DOI-registered output through Crossref or DataCite, but CRediT role tagging in deposit metadata is, in practice, primarily an article-publishing convention today; treatment for datasets and software depends on the registering repository’s own metadata practices.

What do I do if a role I was assigned isn’t showing up?

Work through the dependency chain above — ORCID iD present at submission, publisher deposit actually tagged, auto-update permission granted — using Why ORCID Auto-Update Isn’t Working as a step-by-step diagnostic.

How ORCID Automatically Imports CRediT Contributor Roles

Ask about How ORCID Automatically Imports CRediT Contributor Roles