When to apply When the institution is implementing or consolidating its persistent-identifier strategy across researchers, organisations, projects, datasets, samples, instruments, and outputs — and needs to make the PIDs first-class structured metadata rather than free-text strings.
Before you start
Prerequisites
What needs to be in place before you operationalise The persistent identifier ecosystem terminology in your CRIS or repository.
- An ORCID member account, with at least an ORCID-Trust-Inbox integration in production
- ROR familiarity for organisation identifiers — your institution and your collaborators
- A DataCite or Crossref membership for DOI minting (Crossref for articles, DataCite for datasets and other research outputs)
- A CRIS or repository capable of storing PID strings as typed identifier fields, not freeform metadata
- Awareness of newer PID types — RAiD for projects, IGSN for samples, PIDINST for instruments, Software Heritage IDs for code
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Inventory which entities need which PIDs
Person → ORCID. Organisation → ROR (preferred) and GRID-legacy / ISNI as fallbacks. Project → RAiD where available. Dataset → DataCite DOI. Article → Crossref DOI. Sample → IGSN. Instrument → PIDINST. Software → Software Heritage ID + Zenodo DOI for a release.
Add typed identifier fields to every relevant entity
Each PID is its own typed field with the identifier scheme as metadata. Storing "0000-0002-1825-0097" in a freeform "Identifier" field is not enough — the consumer needs to know it is an ORCID without parsing.
Wire bi-directional sync where the PID supports it
ORCID is the canonical example — your CRIS pushes affiliations, employments, fundings, and works to ORCID, and reads back outputs and affiliations the researcher has added elsewhere. Authentication via the ORCID OAuth flow, not by storing ORCID iDs as guesses.
Add ROR lookup at every organisation-affiliation point
On every form that captures an organisation — co-investigator, partner, funder, employer — replace the free-text field with a ROR lookup that persists both the ROR ID and the display name.
Pilot RAiD or PIDINST for one cohort
RAiD for a multi-institution project; PIDINST for a piece of shared instrumentation. Verify the PID resolves, that linked outputs carry the PID as a relatedIdentifier, and that the CRIS can update the PID record when project membership or instrument status changes.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the The persistent identifier ecosystem pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
ORCID Trust-Inbox or full member integration; OAuth flow for researcher authorisation, then read/write of works, employments, fundings, peer-review.
Free public registry; use the ROR API for org lookup in CRIS and repository forms. The ROR ID, not the display name, is the persistent value.
DOI minting for non-article outputs (datasets, software, models, multimedia). DataCite Commons is the federation discovery layer.
DOI minting for articles, preprints, conference proceedings, books, peer reviews; the metadata deposit also carries Funder Registry IDs and ORCIDs.
Newer PID types — adoption is institution-by-institution. Confirm your CRIS can store and surface these in DataCite-relatedIdentifier semantics before relying on them for funder reporting.
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Storing ORCID iDs as guesses copied from author lists rather than via the OAuth-authorised flow
- Using GRID identifiers (deprecated) when ROR should be the canonical organisation identifier
- Treating DOI as the only PID and routing samples, instruments, and projects through ad-hoc local identifiers
- Failing to register the relatedIdentifier links between PIDs, so the graph cannot be reconstructed downstream
- Letting display names drift away from the canonical PID record — display the value resolved from the PID, do not cache and forget
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The The persistent identifier ecosystem working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
