From journal issue to online store: the journey of a single issue

From the outside, publishing a journal issue looks like pressing a single “publish” button. Anyone who has seen it from the inside knows the truth: it is a marathon of several weeks that begins after the final deadline, filled with emails, correction rounds, and “which one was the final PDF?” questions.

In this post we will follow that marathon step by step — partly as an answer to the general question of how a journal issue comes together, and partly to show how the flow maps onto Nasirus. As our example, let’s take the second 2026 issue of a fictional social-sciences journal: Volume 14, Issue 2.

The issue opens, articles accumulate

The journey actually begins before the issue itself, with the articles. Each article lives through its own review process: submission, editorial screening, reviewer assignment, revision, decision. Accepted articles accumulate in a pool and sit in front of the issue editor.

Here we see journals split into two camps. Some work “issue-based”: articles are accepted and typeset, but readers see the issue only as a whole. Others take the “online-first” approach: an article is published as an early view the moment it is ready and attached to an issue later. Both are legitimate models; what matters is that the journal knows which one it has chosen and that its system supports that model. Nasirus knows both models; at the same institution, one journal can live issue-based while another lives online-first.

The table of contents: the issue’s skeleton

The issue editor’s first concrete task is the table of contents. Which article goes in which order, how are the sections divided (research articles, reviews, book reviews, editorial), what will the page ranges be?

When this is done in Excel, two problems follow. First, the table of contents and the actual state of the articles drift apart: an article sitting in the table is in fact still in revision, and nobody notices. Second, page numbers get updated by hand with every correction that comes back from typesetting, and somewhere along the way they inevitably slip.

This is where having the table-of-contents editor inside the system earns its keep: only genuinely accepted articles can be added to the table, ordering changes by drag and drop, and page ranges live with the article records. The table of contents is not a document — it is the living skeleton of the issue.

Proofs: the discipline of the final read

The draft pages coming back from typesetting go to the authors for a final check. This round — the proof stage — looks minor but is critical for reputation; an article with the author’s name misspelled cannot be fixed after publication.

At most journals, proof tracking runs over email, and that is exactly why it leaks: who approved, who requested corrections, which corrections made it to the typesetter? When the round is defined as a task in the system, “whose approval is still missing” is visible at a glance. Reminders to a late author go out on their own, not by hand.

Publication: one decision, many consequences

And then the issue is ready. The editor makes the publication decision — that decision belongs to a human; no system should publish an issue because “the time has come.” But what follows the decision comes of its own accord: the issue takes its place in the archive, the articles come into their permanent pages, the open-access ones open up to free reading, and the ones for sale step into the store’s shop window.

At a journal where each of these steps is manual, publication day is a checklist day — and the item forgotten on the list usually surfaces weeks later, in an email from a reader.

The online store: the issue’s second life

A published issue’s life in the store falls outside the scope of most journal-management software; yet the reader’s experience begins exactly there. The issue page shows the table of contents, article pages handle purchases or open-access downloads, and a reader with an institutional subscription reaches it through their digital library.

In Nasirus the store is not a separate site; it is the reader-facing surface of the same system. Which is why there is no such task as “exporting the catalog to the store”: when the issue is published, the store is already current, stock and access rights are already correct, and the invoice and ledger entry for the first sale already land in accounting.

After publication: the forgotten last mile

The issue is out, the store is current — done? Experienced issue editors know better: the two weeks after publication day are the quiet but important last mile of the process.

There is announcement work: a “your issue is out” notification to authors (authors should not have to discover this themselves), a new-issue announcement to newsletter subscribers, posts on the institution’s channels. Correction work appears: an author-name fix that slipped through, a DOI match noticed late. And measurement begins: the issue’s access and sales figures, which article is drawing attention.

Making this last mile systematic ties the planning of the next issue to data. A journal that can answer “which article was read most in the last issue?” makes sharper decisions on everything from special-issue themes to call strategy. Journals that treat the publication moment not as a finish line but as the start of measurement feel the difference within a few issues.

Simple on paper, fragile in practice

On paper, an issue’s journey is five steps: collect, order, correct, publish, sell. In practice, dozens of handoffs sit between those five steps, and every handoff is a breakage point where information gets carried by hand from one spreadsheet to another.

The essence of running the process in one system is this: information is entered once, and every stage writes onto the same record. The issue editor’s job becomes deciding, not chasing.

If you would like to hold your own journal’s workflow up against this frame, book a demo and we can walk through issue management using your own examples.