When to apply When integrating a CRIS with internal HR / finance / repository systems, with external aggregators (OpenAIRE, OpenAlex, national databases), or when migrating between CRIS products without losing structured metadata.
Before you start
Prerequisites
What needs to be in place before you operationalise Research-information systems and integration terminology in your CRIS or repository.
- An installed CRIS or research-information system (Pure, Symplectic Elements, Worktribe, Converis, DSpace-CRIS, VIVO)
- Familiarity with CERIF as the EuroCRIS-stewarded reference model for research-information data
- Awareness of the OpenAIRE Guidelines 4.0 metadata profile and the related-identifier semantics that drive federation
- A position on JATS as the article-side metadata target and CERIF as the institutional-side data model
- An identifier strategy aligned with the persistent-identifiers domain — ORCID, ROR, DOI, RAiD
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.
Map entities against CERIF
Person, Organisation, Project, Funding, ResultPublication, ResultProduct, ResultPatent, Equipment, Service, Event. Even if your CRIS uses different internal names, the CERIF mapping is what enables cross-vendor migration and federation.
Define the canonical-source-of-truth for each entity
Person → HR system (with ORCID overlay), Organisation → ROR (external) and HR for internal org tree, Project → CRIS, Output → repository (with CRIS metadata layer), Funding → finance system (with CRIS award entity). Bidirectional sync at boundaries; conflicts resolved towards the canonical source.
Wire CRIS-to-repository handoff
The CRIS holds the project-and-funding context; the repository holds the file and the public record. The CRIS pushes the metadata-of-record to the repository at deposit time, and the repository writes back the DOI and access status. Use SWORD, REST, or the CRIS's native repository connector.
Configure OpenAIRE harvesting and validation
Register the institutional repository for OpenAIRE harvesting; validate that the OpenAIRE Guidelines 4.0 metadata profile produces no upstream errors. Most failures here are missing license, missing access-rights, or missing PID fields.
Test cross-CRIS migration on a sample
Export 50 representative records from the current CRIS as CERIF XML and import into a staging instance of the alternative product. Surface the fields that did not survive — they are your migration risk for the real cutover.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Research-information systems and integration 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.
Native CERIF export, OpenAIRE Guidelines compliance, ORCID and ROR integrations, JATS-aligned output handling. Strong fit for institutions that prefer a single-vendor CRIS.
CERIF-compatible export, Elements Reporting Database for cross-entity queries, strong PubMed and ORCID integrations. Often paired with a separate institutional repository.
UK-focused, native CERIF support, strong on the pre-award and ethics side of the CRIS. Integrates with DSpace and EPrints as institutional repository.
Open-source CRIS layered on DSpace; configurable-entities framework allows custom CERIF-aligned entity types. Lower licensing cost; higher integration-engineering cost.
Open-source researcher-profile platform with the VIVO-ISF ontology; pairs well with another CRIS as the public-facing profile layer rather than the operational CRIS.
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.
- Treating the CRIS as the canonical source for entities (Person, Organisation) that should round-trip to HR and ROR
- Skipping the CERIF mapping and discovering at migration time that fields do not have a clean target
- Failing to wire bidirectional CRIS-to-repository sync, so the DOI minted at the repository never reaches the CRIS record
- Ignoring OpenAIRE harvesting failures because they are silent — the records are dropped from the federation graph and no one notices
- Mixing public profile and operational CRIS into one product without separating the access controls — researchers see fields they should not edit, and curators struggle with public-facing curation work
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Research-information systems and integration 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.
