Roles and permissions at a publishing house: should everyone see everything?

At small publishing houses, permissions look like a non-problem: three people do everything together, and everyone knows everything. The problem begins with the fourth person. Someone joins to handle the accounts, a student assistant takes over the online store, a freelance typesetter comes on board — and one day it dawns on everyone that the folder holding the publishing contracts is open to all of them.

Permission design is a matter of care, not of distrust. In this post we will lay out how a publisher should think about its roles, and what the principle of “everyone sees only their own work” looks like in practice.

A role is really a bundle of permissions

Names like “editor,” “editorial office,” “accountant” are job titles in everyday speech; in software, each is a bundle of permissions. The editorial office can check submissions for completeness but cannot make an acceptance decision. The commissioning editor can assign reviewers but cannot close an accounting period. The printer sees only their own print jobs.

This bundle approach has two practical consequences. First, one person can hold several roles — at small institutions the same person is both editor and production manager, and that is entirely normal. Second, permissions attach to the role, not the person: when the editor changes, the whole job is giving the role to the new person; nobody lies awake wondering “were the old editor’s accesses all revoked, one by one?”

Screen-level permissions aren’t enough: three layers

Building permissions only at the level of “who sees which page” is the most common shortfall. A sound model works in three layers:

1. Screen level: The accountant enters the accounting dashboard. Simple and necessary — but insufficient on its own.
2. Workflow level: Whatever stage a work is at, only that stage’s owner sees that stage’s actions. The “Accept” button is absent from the editor’s screen while the work is under review — because at that moment it is not the editor’s job.
3. Relationship level: Of two people holding the same role, only the one connected to the work sees it. A reviewer sees the file of the work they are assigned to — not the hundred other works in the pool. An author sees their own draft; a work in draft status is visible to no one but its owner.

The third layer is the least discussed and the most critical, because it is where double-blind review is protected in everyday practice.

Five surfaces: one system, separate doors

Nasirus carries this thinking into the architecture: one system, used through five separate surfaces. Readers see the store; authors, reviewers, and editors see the application dashboard; the publishing operation sees the management dashboard; the accountant sees their own dashboard; the store operator sees the commerce dashboard.

The beauty of this separation is that it abolishes the category of “by accident.” The store operator cannot stumble into the editorial workflows, nor a reviewer into production correspondence — because that door does not exist on their surface. A reader who signs up through the store carries no permissions over to the dashboard side; the reader’s world and the institution’s world live separately.

The small-press objection: “There are three of us — isn’t this overkill?”

Explain role design and small publishers always raise the same objection: “This is big-institution stuff; here, everyone does everything anyway.”

There are two answers. The first is practical: the role model works at a small institution too — you simply give one person several roles. In a three-person press, one person can be editor + production manager, another editorial office + store operator. The roles the system sees are precise; people are free to switch hats. When the institution grows, the only work left is to separate the hats — not to rebuild the system.

The second is discussed less: at a small institution, some separations are even more critical than at a large one. In a three-person team, “who touched the accounting records” already answers itself; but the moment the freelance typesetter, the translator, and the printer start logging in — and that is precisely where the real efficiency gains are — the inside-outside boundary becomes vital. The external partner seeing only their own task is the minimum fence protecting a small press’s contracts and author data.

In short, the role model is not a “corporate luxury”; set up when the team is three, it scales to ten without effort — attempted at ten, it is painful.

“But what about emergencies?” — even the exception leaves a record

The classic objection to permission design runs: “If the rules are rigid, work stops in an emergency.” A fair worry; the answer is not to loosen the rules but to make the exception auditable.

A mis-recorded step being reversible by someone authorized is a good example: the undo exists, but it is never unrecorded. In an emergency the door opens — and who passed through it, when, and on what grounds is known as well. The exception is allowed; the traceless exception is not.

The starting question for your own institution

If you want to review your role scheme, start with a single question: “Does this person need to see this information to do their job?” If the answer is no, they shouldn’t see it — not out of distrust of the person, but out of the responsibility that author data, reviewer identities, and financial records carry.

Ask that question for every role in your institution, and the table you end up with is not “custom development” in good software — it is day-one configuration. If you would like to build your own role table together, book a demo — and bring your accountant and your store manager along; the best questions come from them.