Managing ReferencesThe Status Workflow

The Status Workflow

The reference lifecycle from draft to public — stages, roles, the editor stepper, rejection comments, the status history, and the kanban board.

Every reference travels a defined path from first draft to public visibility. The status workflow turns the raw per-language statuses into one clear, ordered lifecycle: the editor shows where a reference stands, who it currently lies with, and which steps you — in your role — may take next. Every change is recorded in a per-reference status history, and the kanban board shows the whole portfolio by stage.

The lifecycle

StageWho actsMeaning
Created (optional)Manager / systemPre-state for references created automatically, e.g. by an import.
In progressManagerDraft, content work ongoing.
SuggestedManagerProposed for content approval — the responsible reviewers are notified.
Content rejectedReviewerSent back with a mandatory comment; the manager reworks and proposes again.
Content approvedReviewerThe first safe spot: content quality is confirmed.
Proposed for publication (two-stage only)ReviewerHanded to the publishers — they are notified.
Public release rejected (two-stage only)PublisherPublication declined with a mandatory comment. The reference stays content-approved — it falls back to the safe spot, never to draft.
Public 🌐 ✅PublisherThe second safe spot: published on the selected channels.
WithdrawnPublisherTaken off the public platform; the content is preserved.

The two green safe spotsContent approved and Public — are stable resting states. Rejections at the publication stage never undo the content approval: a publisher's "not yet" drops the reference back to Content approved, not to the drawing board.

One-stage or two-stage approval

How much process a reference needs depends on the size of your organization, so the workflow comes in two modes:

Content approval is the release decision. Once a reference is Content approved, anyone with review or publishing permission can set it public directly. The publication-proposal stages don't appear anywhere — smaller teams keep a short, simple flow.

The mode is a per-company setting. Today it is enabled per company on request; a company settings manager where administrators switch it themselves is coming soon.

Roles

The workflow uses the same permissions as the rest of the platform:

RolePermissionMay…
Manager (writer)Edit referencesedit content, propose it for content approval, rework rejected references
Reviewer (Controller)Reference reviewapprove or reject content, propose publication (two-stage)
PublisherPublish reference profilepublish, reject a publication, withdraw a public reference

Only the steps allowed for your role in the current stage are offered — in the editor, and as drop targets on the kanban board. The server re-checks every transition, so the UI is a convenience, not the security boundary.

The stepper in the editor

The Status & publication tab of the reference form opens with a horizontal stepper:

  • All stages in order, with the current state highlighted; the two safe spots are marked green, a rejection state amber.
  • Currently with names the person(s) the reference is waiting for — resolved from the reviewer assignment of the reference's groups and its responsible location. If no specific reviewer is assigned, the stage shows the responsible role (e.g. Role: Controller) instead of listing everyone who holds the permission.
  • Below it, action buttons for exactly the steps your role may take next.

A few behaviors worth knowing:

  • Proposing opens the notification block. Propose for content approval (and Propose for publication) preselects the target status and opens the familiar notification section with the responsible reviewers or publishers suggested — you choose the recipients and an optional message, and everything is sent when you save.
  • Rejections require a comment. Reject content and Reject publication open a comment field; the comment is mandatory, is delivered with the notification to the people who need to act, and is stored in the status history. The latest rejection comment is shown as a banner right in the stepper.
  • Statuses are per language. The stepper works on the language version you are editing; a language switch above it changes the view. Publication itself is one decision for the whole reference — see Publishing References for how per-language approval and the public flag combine.

The per-language status dropdowns below the stepper remain available as a direct control for experienced users — the stepper and the dropdowns always stay in sync.

The status history

Every status change writes an entry to the reference's status history, shown as a timeline at the bottom of the status tab: date and time, who made the change, from which stage to which — and the comment, if one was given. The history is append-only; it cannot be edited or deleted, which makes it a reliable audit trail for questions like "who published this, and when?" or "why was this rejected in March?".

Publication changes (public / withdrawn) are recorded reference-wide; content-status changes are recorded per language version.

The kanban board

The reference manager has a kanban view next to list and tiles: one column per lifecycle stage, every reference as a card in the column of its current stage. Safe-spot columns are marked green, rejection columns amber.

  • Drag & drop performs the transition. While dragging a card, only the columns that are legal next steps for your role light up as drop targets — everything else is dimmed. Dropping into a rejection column asks for the mandatory comment first. An illegal move simply snaps back.
  • Two person filters narrow the board: Responsible person filters by the reference's responsible contact, Currently with filters by whom a card is waiting for (the same resolution as the stepper).
  • The board operates on one content language at a time — switch between languages above the columns.
  • The board loads the first 100 references matching your current filters; use the regular filters to narrow a larger portfolio.

The board is a faster way to do what the stepper buttons do — not a bypass. Every drop is validated on the server against your role and the current stage, and logged in the status history like any other transition.

Notifications along the way

Hand-overs notify the people who need to act, by inbox message and — depending on each recipient's settings — by e-mail:

TransitionWho is notified
Propose for content approvalThe responsible reviewers (per group and location assignment)
Reject contentThe reference's responsible manager, with the comment
Propose for publication (two-stage)The publishers
Reject publication (two-stage)The reviewers, with the comment

Frequently asked