Kapitel 2 · Für Editoren

Freigeben & veröffentlichen

Vom Entwurf zur sichtbaren Seite: CAMPUS kennt einen klaren Freigabe-Workflow, damit nur geprüfte Inhalte live gehen. Diese Seite erklärt die Zustände, die Rollen, den konkreten Ablauf und was Sie vor dem Veröffentlichen prüfen sollten.

Warum es einen Workflow gibt

Ohne geregelte Freigabe landet jeder Entwurf sofort bei den Nutzern — mit Tippfehlern, halben Sätzen und ungeprüften Aussagen. Der Workflow trennt Arbeiten von Veröffentlichen: Sie bauen in Ruhe, jemand prüft, dann geht es live. Das schützt Qualität und Vertrauen.

Die Zustände & Übergänge

Jedes Product durchläuft Zustände; die Übergänge haben feste Namen (auch in der API):

Entwurffresh →request_approval zur Freigabepending →approve Veröffentlichtactive →archive Archiviertarchived

Aus Archiviert holt der Übergang refresh ein Product zurück in die Bearbeitung. Direktes Veröffentlichen (publish/activate) ist möglich, wenn Sie das Recht dazu haben.

Wer darf was? (Reviewer)

Ob Sie selbst veröffentlichen dürfen oder nur „Freigabe anfragen" können, hängt von Ihren Rechten ab (Feld canPublish). Das Prüfen & Genehmigen übernimmt die Rolle Reviewer — ein zuschaltbares Recht (siehe Rollen & Rechte). So entsteht ein sauberes Vier-Augen-Prinzip: Editor erstellt, Reviewer gibt frei.

So geht's konkret

So geht's konkret: freigeben & veröffentlichen
  1. Fertig stellenInhalt, Sprache(n), Kategorien/Tags und Zugriff prüfen.
  2. Freigabe anfragenAm Product den Status auf „Freigabe anfragen" setzen (request_approval).
  3. Prüfen lassenEin Reviewer sieht die Anfrage, prüft und genehmigt (approve) — oder gibt sie mit Hinweisen zurück.
  4. VeröffentlichenNach Freigabe wird das Product aktiv und für die Zielgruppe sichtbar.
  5. Später pflegenVeraltetes archivieren; zum Überarbeiten mit refresh zurückholen.

Prüf-Checkliste vor dem Veröffentlichen

  • Alle Sprachen? Titel, Lead und Inhalt je aktiver Sprache (mind. DEFAULT).
  • Kategorien & Tags? Sonst wird der Inhalt schlecht gefunden.
  • Zugriff korrekt? Öffentlich, Gruppe oder Restriction-Preset wie gewünscht.
  • Hero-Bild & Vorschau? Der erste Eindruck zählt.
  • Links & Medien? Funktionieren, richtige Assets, Rechte geklärt.
⚠️

Sichtbarkeit ≠ Berechtigung. Veröffentlichen macht ein Product „live" — die tatsächliche Sichtbarkeit steuern zusätzlich die Restrictions. Prüfen Sie im Zweifel mit einem Testkonto der Zielgruppe.

Troubleshooting

Ich sehe keinen „Veröffentlichen"-Knopf, nur „Freigabe anfragen".

Dann fehlt Ihnen das canPublish-Recht. Das ist Absicht (Vier-Augen-Prinzip) — ein Reviewer/Admin gibt frei.

Veröffentlicht, aber Nutzer sehen nichts.

Fast immer eine Restriction oder eine fehlende Kategorie. Empfänger/Sichtbarkeit mit Testkonto prüfen.

Ich muss eine veröffentlichte Seite korrigieren.

Bearbeiten Sie sie im Edit-Mode; je nach Konfiguration durchläuft die Änderung erneut die Freigabe. Für größere Umbauten ggf. archivieren und mit refresh neu aufsetzen.

Verwandtes

👉

Zum Abschluss des Kapitels: How to: perfekte Inhalte.

Chapter 2 · For editors

Approve & publish

From draft to a visible page: CAMPUS has a clear approval workflow so that only reviewed content goes live. This page explains the states, the roles, the concrete process and what you should check before publishing.

Why there is a workflow

Without a regulated approval, every draft lands with users immediately — with typos, half sentences and unreviewed statements. The workflow separates working from publishing: you build in peace, someone reviews, then it goes live. This protects quality and trust.

The states & transitions

Every product goes through states; the transitions have fixed names (also in the API):

Draftfresh →request_approval for approvalpending →approve Publishedactive →archive Archivedarchived

From Archived, the refresh transition brings a product back into editing. Direct publishing (publish/activate) is possible if you have the right to do so.

Who may do what? (Reviewer)

Whether you may publish yourself or can only “request approval” depends on your rights (field canPublish). The reviewing & approving is handled by the Reviewer role — an addable right (see Roles & rights). This creates a clean four-eyes principle: the editor creates, the reviewer approves.

Step by step

Step by step: approve & publish
  1. FinaliseCheck content, language(s), categories/tags and access.
  2. Request approvalSet the product status to “Request approval” (request_approval).
  3. Have it reviewedA reviewer sees the request, reviews and approves (approve) — or returns it with notes.
  4. PublishAfter approval the product becomes active and visible to the target group.
  5. Maintain laterArchive outdated content; bring it back for revision with refresh.

Review checklist before publishing

  • All languages? Title, lead and content per active language (at least DEFAULT).
  • Categories & tags? Otherwise the content is hard to find.
  • Access correct? Public, group or restriction preset as intended.
  • Hero image & preview? The first impression counts.
  • Links & media? Working, the right assets, rights clarified.
⚠️

Visibility ≠ authorisation. Publishing makes a product “live” — the actual visibility is additionally controlled by the restrictions. When in doubt, check with a test account of the target group.

Troubleshooting

I don’t see a “Publish” button, only “Request approval”.

Then you lack the canPublish right. That is intentional (four-eyes principle) — a reviewer/admin approves.

Published, but users see nothing.

Almost always a restriction or a missing category. Check recipients/visibility with a test account.

I need to correct a published page.

Edit it in edit mode; depending on the configuration the change goes through approval again. For larger rebuilds, archive it if necessary and set it up anew with refresh.

Related

👉

To close the chapter: How to: perfect content.