OJS Administration: Tasks and Evidence for Journal Portals

OJS Administration: Tasks and Evidence for Journal Portals

OJS administration for an institutional portal needs tasks assigned per journal, a person who approves each change and evidence of what was checked. An operational matrix lets you tell a technical problem from a pending editorial decision, without turning the editor into a server administrator.

What institutional OJS administration should cover

Define the portal's shared operation and each journal's particular responsibilities before setting a routine. PKP describes OJS as open-source software for managing academic journals.[1] The specific distribution of work, however, is something you must agree on with your institution and with whoever operates the platform.

We recommend separating a common portal sheet from a sheet per journal. The first identifies infrastructure, domain, email, administrative access and institutional dependencies. The second gathers the editorial contact, approval owners, integrations in use and pending commitments. This separation works for a shared installation as well as for several installations under institutional coordination.

If you are still receiving the platform, start with the OJS implementation checklist. The goal here is different: to sustain the work after that handover and to make visible who must act when something changes.

Operational matrix: editor, IT and provider per journal

Assign an executor and an approver to each task; avoid leaving a row to an abstract institution. The executor performs the check or the change. The approver accepts its result and decides on its consequences within their authority.

The following matrix is a working proposal, not a description of OJS permissions or contractual obligations. Replace the roles with people and complete one copy per journal.

A task is not closed when it is executed: it requires approval and reviewable evidence.

Task	Who executes	Who approves	Evidence you should ask for	Pending item that must stay visible
Access creation, replacement and removal	Editorial manager; IT or provider if technical intervention is needed	Editorial owner for their journal; IT for server access	Authorized request and verification of the agreed access	Removal not confirmed or missing authorization
Editorial email	IT or provider checks delivery; editor confirms receipt	Editorial owner accepts the test; IT authorizes domain changes	Test message and delivery result	Institutional account or DNS change pending
Scheduled tasks	IT or provider, according to the agreed scope	Portal technical owner	Execution log and expected result	Failed, delayed or undiagnosed task
Backup and restoration	IT or designated provider	Technical owner accepts the test; editor reviews the sample for their journal	Backup log and test restoration record	Incomplete copy or pending test
DOIs and metadata	Editor reviews content; designated operator manages the deposit	Editorial owner and institutional owner of the registration	Deposit result and verified link	Rejection or metadata to correct
Journal data in DOAJ, if applicable	Person authorized by the journal	Editorial owner	Update request and observed status	Change submitted but not yet reflected

When IT and the provider share a task, specify who takes the next step. For example, the provider may diagnose an email problem while IT keeps the authorization to modify the domain. Write that dependency down; do not mark the task as resolved just because the diagnosis is finished.

Keep passwords and keys out of this matrix. Record who holds custody of the credentials and how to request an authorized intervention, without turning the portal report into an inventory of secrets.

OJS maintenance by risk and event

Combine scheduled reviews with event-triggered actions. The frequencies below are indicative: we propose adjusting them to editorial volume, available resources and the damage a failure would cause. They are not PKP, Crossref or DOAJ requirements.

Recommended control	Indicative frequency or event	Review criterion
Availability and critical errors	Alerts according to the agreed risk; immediate review when a notice arrives	Confirm scope and start the response procedure
Email	After failures, domain changes or credential changes; agreed periodic test	Check receipt, not just that the message was sent
Scheduled tasks	After their expected execution and after technical changes	Identify missed runs or anomalous results
Backups	After each planned run	Review the result and the availability of the copy
Restoration	On the continuity calendar and after relevant changes	Recover in an isolated environment and review the agreed sample
Access	On joining, leaving or change of role; periodic reconciliation	Compare current authorization with actual access
Version and components	On relevant notices and before approving changes	Assess applicability, testing and the possibility of rollback
Portal pending items	Suggested monthly consolidation	Make decisions on open exceptions

The monthly report gathers results; it should not delay the response. A domain expiry, an email outage or a sign of an incident requires action when it is detected. Also define who receives the alerts if the usual person is absent, with coverage that has genuinely been agreed.

For backups, ask that the test distinguish technical recovery from editorial acceptance. In a hypothetical example, the system opens again, but files from one journal are missing. The restoration stays pending until that difference is reviewed. The procedure should state which copy was used, what was recovered and who verified the contents.

DOIs and DOAJ records: responsibilities that continue

Keep an owner for metadata after publication and record the changes that require external actions. Crossref includes among its members' commitments keeping the DOI resolving to an active landing page.[2] That is why we recommend that closing a DOI task include checking the link and the expected content, in addition to the deposit result.

If the location of the pages changes, Crossref says to update the resolution URLs.[4] Note who prepares the change, who authorizes it and how it is verified. A change to the portal's domain should trigger this review for the affected journals, without waiting for the next meeting.

For journals included in DOAJ, the entity asks to report changes and keep records up to date.[3] We recommend comparing the change approved by the journal with its public information and the status of the request. Distinguish between a prepared request, a submitted one and a change that is reflected. Do not present them as the same result.

A monthly review can serve as an additional institutional control, but do not attribute it to DOAJ as a periodicity requirement. Nor should you confuse this management with a guarantee of indexing: ordering responsibilities does not determine an external entity's decision.

Exception report for the journal portal

Consolidate exceptions in a common report that allows decisions without dumping the complete technical records. We recommend including the affected journal, observed problem, editorial impact, executor, approver, available evidence, dependency and next action.

Use unambiguous statuses: verified, pending, blocked or not applicable. If something is blocked, identify the missing decision or input. If it is verified, link evidence with a date and scope. A green box with no explanation is not enough.

A hypothetical example: one journal is not receiving notifications and another is waiting for approval of a contact change. The report should separate both cases. The first requires a technical diagnosis and a new receipt test; the second requires an editorial decision. Grouping them under "support pending" makes it impossible to see who should move forward.

For shared failures, create a portal exception and link the affected journals. Avoid opening disconnected incidents that repeat the diagnosis. When closing, record the checks performed per journal: that one publication works does not show that all of them have been reviewed.

Restrict access to sensitive evidence. The management report can describe the result without attaching manuscripts, personal data or complete logs that the person receiving it does not need.

Institutional work plan: operation, migration and training

Separate recurring work from change projects and from training. That way you can approve specific deliverables without assuming that hiring one activity covers the others.

We recommend organizing the plan in independent lines:

• Recurring operation maintains controls, handles exceptions within the agreed scope and keeps evidence. It must identify institutional dependencies and excluded tasks.
• Migration or upgrade has a source inventory, tests, authorization of the change and its own acceptance criteria. Its closing must return an updated operational sheet.
• Training prepares people for specific tasks. Define the participating roles and an exercise that makes it possible to verify learning, without presenting it as a substitute for technical maintenance.

To prioritize, distinguish what stops the editorial workflow from an improvement that can be scheduled. Then assign an owner and a closing condition. An urgent problem should not stay hidden among design requests, and a postponed improvement needs an explicit decision.

When evaluating external support, hand over the matrix and ask for an answer on each row: who executes, what it requires from IT, what the journal approves and what evidence will be delivered. The conditions for service, continuity and exit must be in the applicable agreement. Do not deduce them from the name of a plan.

Common mistakes when distributing OJS operations

Avoid closing tasks for activity performed when their result has not been verified. In this operational proposal, these are control errors worth looking for during the review:

• Reporting "email configured" without confirming receipt in the agreed mailboxes. Keep the test pending until you get that result.
• Presenting a backup record as evidence of restoration. These are different checks and must have separate statuses.
• Assigning IT the approval of editorial policies. Ask the journal for the decision and reserve technical intervention for applying the authorized change.
• Considering that an external pending item is finished once a request is sent. Keep its status until you verify the response or the corresponding change.
• Granting broad permissions to cover an absence. First agree the task and the access needed; record the authorization and its later review.

Also review the rows nobody claims. A task without an executor can look shared for months; in practice, nobody knows when to step in. A useful closing identifies the observed result, the person who accepts it and any exception that remains open.

Frequently asked questions

Does a common matrix replace each journal's sheet?

No. The common matrix defines the working model, but each journal needs identified people, applicable integrations and its own pending items. You can consolidate the portal's exceptions without erasing those differences or assuming that all journals use DOIs or are included in DOAJ.

Who approves a change that affects the whole portal?

We recommend that the institution designate a person with authority over the portal who coordinates the editorial acceptance of the affected journals. The technical executor prepares the change and its tests; they should not assume institutional approval or scientific decisions by default.

How do you know a pending item is really closed?

Define the evidence beforehand and who will accept it. For email it may be a verified receipt; for recovery, a test with a review of the contents. If an authorization or an external action is missing, record that dependency and keep the pending item open.

Agree on an operation with verifiable tasks

Start with a complete matrix and with the exceptions that require a decision. With those documents you can compare your internal capacity with the external support you need, without delegating the institution's editorial responsibilities.

Review OJS ONE Core operation and request an evaluation with your portal's inventory, its dependencies and pending tasks. Agree on which activities will be covered and how you will verify their result before approving the work plan.

Sources

1. PKP, official Open Journal Systems repository — accessed 2026-10-22.
2. Crossref, Maintaining your metadata: DOI continuity — accessed 2026-10-22.
3. DOAJ, Publisher information: updating records — accessed 2026-10-22.
4. Crossref, Maintaining your metadata: resolution URLs — accessed 2026-10-22.