Frequently asked questions.

Inrep Scholar is an institutional repository platform for universities, libraries and research offices. It supports final-year projects, theses, dissertations, journal articles, datasets, public discovery, and compliance reporting, with a review workflow that routes submissions through a supervisor and a librarian before publication.

InRep Connect links to files an institution already hosts elsewhere. InRep Cloud stores files inside Inrep Scholar's own private storage, with a protected viewer and access controls. InRep Campus is installed on the institution's own server — students, staff, submissions and files stay on that server, and only approved published metadata syncs to the central discovery index.

Yes. The platform supports institution-specific repositories, dashboards and public pages, with tenant boundaries enforced on the server for every request — a user from one institution cannot reach another institution's private records by changing a URL, slug, form value or record ID.

Yes. Existing PDFs can be uploaded record by record, or imported in bulk through the bulk upload workflow with row-level validation and duplicate detection.

Yes. The platform is built with PHP and MySQL, so it can be deployed on standard hosting that supports the required PHP extensions and storage permissions — InRep Campus in particular is designed to install on a university's own cPanel or server.

Yes. All of the public research tools are free for anyone browsing Inrep Scholar, with a fair-use rate limit to keep the service available for everyone. No account is required to use them — signing in is only needed to submit or manage your own records.

Tool inputs are used only to generate the requested result and are not published or shared. Published repository records used for search and comparison follow each record's own access policy — a restricted or embargoed record is never surfaced through a public tool result.

A submission moves through a defined workflow: the assigned supervisor reviews it and can approve it or request a correction; once approved, it goes to a librarian for metadata and access review, who publishes, embargoes, requests a correction, or rejects it. Every stage change is recorded, and a corrected submission returns to the same reviewer rather than skipping the queue.

Yes. Records can be set to open access, metadata-only, view-only, institution-only, restricted (request-and-approve), or embargoed until a set date — the access rule is enforced on every download and viewer route, not just hidden in the interface.

Yes. Faculties, departments and programmes are available as metadata and reporting filters, while supervisor and librarian review remains the final repository workflow regardless of department structure.

Final-year projects, theses, dissertations, journal articles, preprints, datasets and other institution-defined document types can each carry their own metadata fields and access defaults.

A librarian can send an incomplete record back with a correction request during metadata review instead of publishing it — the record shows a correction-requested status to the submitting student or researcher, who can resubmit once the missing metadata or file issue is fixed.

Compliance and repository-readiness reports (including NERD-style reporting) are generated from the same structured submission and access data every record already carries, so reporting reflects what has actually been reviewed and published rather than a separate manual return.

Records can be entered directly, imported in bulk from a spreadsheet, or brought in through the bulk import workflow's format detection and duplicate checking — each import path runs the same metadata and access validation as a manual submission.

Students and researchers register directly on their institution's public repository page. Institutions can require a school email domain, and email verification uses a one-time code before an account becomes active.

Institution admin, focal person, compliance officer, librarian, repository manager, supervisor, lecturer, examiner, reviewer, student and researcher roles are supported, each scoped to what that role needs — role checks are enforced on the server for every protected action, not only hidden from the menu.

Yes. An institution's public repository pages can carry its own name, logo and contact details, whether it is on InRep Connect, Cloud or Campus.

Every institution's student population, storage volume, integration and support needs are different, so we prepare a tailored quote instead of a fixed rate. Tell us what you need through the request-setup form and we'll send a proposal.

No. Institutions subscribe and pay for their repository; individual students, researchers and staff are never redirected into a payment flow.

InRep Campus is the highest tier. It provides a dedicated university-hosted repository application, federation with central discovery, signed licensing, deployment controls, and priority implementation support.

Campus supports monthly or yearly terms. Connect and Cloud remain annual plans and can be purchased for one to five years.

Connect retains files in the systems you already operate. Cloud stores them in Inrep Scholar's private storage, with a protected viewer. Campus stores them only on your own university server.

Before a subscription lapses, the institution is reminded ahead of the renewal date.

InRep Campus: the local repository enters a read-only safety mode — public access, administrator login, backups, exports, and renewal remain available; uploads, publishing, sync, updates, and new credentials stop until renewal.

InRep Connect / InRep Cloud: the institution's own copy of its data is never affected — a lapsed subscription affects central discovery indexing, updates, and support, not data ownership.

Yes. Campus includes a controlled migration workflow so eligible central records and files can be imported into the university-hosted application.

Hosted Inrep Scholar (InRep Connect / InRep Cloud): Institutional data, user accounts, repository metadata and uploaded research files (for Cloud) are stored on Inrep Scholar's hosting infrastructure. The specific hosting region and data-location arrangements are documented in the institution's service agreement and Data Processing Agreement.

InRep Campus: Campus is installed on infrastructure controlled or selected by the subscribing institution. The institution determines the hosting provider, server location, and backup arrangement, and is responsible for meeting its own data-residency requirements.

Inrep Scholar uses role-based access control — a user can only reach the functions and records permitted for their assigned role and institution. Institution-level authorization is validated on the server for every protected request; a user from one university cannot reach another university's private records by changing the university slug, a URL, a form value, or a record ID. Restricted, embargoed, and institution-only records additionally require an approved access request before the file itself is reachable.

The hosted edition (InRep Connect / InRep Cloud) runs on managed, internet-accessible server infrastructure. InRep Campus can be deployed on an institution's own selected cloud account, private server, or approved hosting environment — the institution remains responsible for infrastructure-level controls in any environment it manages itself.

Inrep Scholar applies layered security controls including encrypted HTTPS connections, secure password hashing, role-based authorization, tenant isolation, server-side input validation, protected document access, and controlled administrative permissions.

Additional controls already in place include: time-limited document access links, active-account validation, PDF watermarking on protected views, file-type and upload validation, restricted and embargoed publication access, supervisor and librarian approval gates before publication, secure session handling, rate limiting on authentication and one-time-code operations, and audit logging for sensitive administrative actions.

We do not claim ISO certification, independent penetration testing, encryption at rest, or Cyber Essentials certification unless that evidence has been issued and can be supplied on request.

Inrep Scholar maintains scheduled backups of repository data and uploaded files. Backup frequency, retention periods, and recovery arrangements are defined in the applicable service plan and institutional agreement, and backup restoration procedures are periodically tested. For InRep Campus, the institution's own backup schedule applies to its self-hosted installation.

Inrep Scholar maintains documented procedures for responding to infrastructure failure, data corruption, security incidents, and extended service interruption. The process covers service restoration, backup recovery, incident escalation, institutional communication, and post-incident review. Specific recovery-time and recovery-point targets are set out in the institutional agreement rather than published generally, since they depend on the subscribed plan.

Data location and any international-transfer arrangement depend on the hosting configuration selected for the institution; any cross-border processing or storage arrangement is disclosed in the applicable service agreement and Data Processing Agreement. For InRep Campus, the institution controls the hosting location and is responsible for selecting infrastructure that satisfies its own data-residency requirements.

Yes. A Data Processing Agreement can form part of institutional onboarding and contracting. It sets out the responsibilities of the institution and Inrep Scholar, permitted processing activities, confidentiality and security obligations, subprocessors, incident handling, data retention, and contract-termination procedures. Request one through the contact form or during onboarding.

Contact us for a Data Processing Agreement →

Infrastructure providers and other subprocessors are reviewed before they are authorised to process institutional data, covering security controls, service availability, data location, backup arrangements, incident reporting, and contractual safeguards. A current subprocessor list is available on request as part of the Data Processing Agreement package.

Inrep Scholar supports the controlled review, correction, export, and deletion of eligible personal account information, subject to institutional responsibilities, applicable law, and legitimate academic-record or repository-retention requirements. Published research records receive separate handling from personal account data — deleting a user account does not automatically remove an institution's legitimate scholarly record. Anyone can submit an access, correction, export, or deletion request through the Trust Center.

Submit a data subject request →

User account and operational information is retained only for as long as needed to provide the service, meet contractual obligations, and satisfy applicable institutional policy. Published research, repository metadata, and institutional records may be retained for long-term scholarly preservation according to the institution's own repository policy — retention periods for account data are configurable per institution rather than fixed platform-wide.

Published or embargoed repository content is retained as part of the institution's scholarly archive; long-term preservation of published research is a core purpose of the platform, not an optional extra. Archived records remain governed by their access classification, embargo conditions, and institutional repository policy.

Eligible records move through a controlled deletion lifecycle: an item is deactivated, moved to a recycle bin, and only permanently purged after explicit, typed confirmation from an authorised administrator — restore remains possible until that final step. Permanent deletion removes the record from the active database and stored files, and is recorded in the audit trail; removal from any retained backups follows the backup retention period in the applicable agreement.

Hosted Inrep Scholar: Before termination, the institution can request an export of its repository metadata, account records, and eligible uploaded files. After the agreed export and transition period, institutional data is deleted or anonymised according to the contract, retention policy, and applicable legal obligations.

InRep Campus: Data remains on the institution-controlled installation at all times. Central indexing, updates, support, and subscription-dependent services may be disabled after termination, but the institution's own server and files are never touched by Inrep Scholar.

No. Research documents, submission information, and private institutional records are not used for unrelated direct marketing. Marketing communications are sent only through authorised channels, with unsubscribe controls.

Standard accounts use password-based login with secure password hashing. Administrator and InRep Campus admin accounts additionally require a one-time email code at login. Single sign-on is available for institutions that configure it — Microsoft sign-in is supported directly, and SAML/OAuth identity providers and LDAP directories can be connected for institutions that already run one. Multi-factor authentication beyond the email one-time code (such as an authenticator app) is not currently offered as a standard option.

An institution administrator can disable a departing user's account at any time, which immediately removes their ability to sign in. Records they submitted or reviewed remain part of the institution's scholarly archive and audit trail — disabling an account does not delete the institutional record of work they were involved in, consistent with how published research is retained under the institution's own repository policy.

For hosted Inrep Scholar (InRep Connect / InRep Cloud), the institution is generally the data controller for its own students', staff, and researchers' personal information, and Inrep Scholar acts as processor under the terms set out in the Data Processing Agreement. For InRep Campus, the institution controls the infrastructure and application directly, so it holds both roles for data on its own installation. The precise allocation for a given institution is confirmed in its own agreement rather than fixed generally, since it can depend on local regulatory requirements.

Report a suspected security issue, vulnerability, or incident through the contact form, marking it as a support/security matter so it is routed and prioritised correctly. Include enough detail to reproduce or verify the issue; do not include real personal data, credentials, or sensitive record content in the report itself.

Report a security concern →