Workflows

Workflows verwandeln eine Status-Spalte in eine strukturierte Prozess-Engine. Statt dass jeder den Status einer Zeile jederzeit frei ändern kann, definieren Sie genau, welche Übergänge erlaubt sind, wer sie auslösen darf, welche Bedingungen erfüllt sein müssen und was nach einem erfolgreichen Übergang automatisch geschieht. So werden Copera Boards vergleichbar mit dedizierten Prozesstools wie Jira oder ServiceNow — direkt in Ihrem Workspace.

Einen Workflow aktivieren

Workflows werden pro Status-Spalte einzeln konfiguriert. So aktivieren Sie einen:

1. Öffnen Sie Ihr Board und gehen Sie zur Tabelle mit der Status-Spalte, die Sie steuern möchten.
2. Klicken Sie auf den Spaltenkopf, um die Spalteneinstellungen zu öffnen.
3. Schalten Sie den Workflow-Schalter ein.
4. Der visuelle Workflow-Editor erscheint — eine Canvas, die jeden Status als Knoten und jeden erlaubten Übergang als gerichteten Pfeil zeigt.
5. Setzen Sie einen Initial Status — den Status, mit dem neue Zeilen starten.

tipp

Beim ersten Aktivieren des Workflow-Modus bietet Copera vorgefertigte Vorlagen für gängige Prozesse wie Software Development (Backlog → In Progress → Code Review → QA → Done), IT Service Desk, HR Onboarding und Content Approval. Eine Vorlage befüllt Status und Übergänge und gibt Ihnen einen soliden Startpunkt zum Anpassen.

Statusübergänge

Ein Übergang definiert einen erlaubten Pfad zwischen zwei Status. Ohne definierten Übergang ist die Statusänderung blockiert.

Benannte Übergänge

Jeder Übergang kann einen Anzeigenamen haben, der erscheint, wenn Benutzer den nächsten Schritt wählen — z. B. „Start Review“, „Approve“ oder „Send Back for Revisions“. Klare Namen helfen dem Team, jede Aktion im Prozesskontext zu verstehen.

Spezifische Übergänge

Ein spezifischer Übergang verbindet einen bestimmten Status mit einem anderen. Im visuellen Editor ziehen Sie von einem Statusknoten zum anderen. Beispiel: „To Do“ direkt mit „In Review“ verbinden erlaubt nur diesen einen Pfad.

Globale Übergänge

Ein globaler Übergang geht von jedem Status zu einem bestimmten Ziel. Nützlich für Aktionen, die immer möglich sein sollen — z. B. „Cancel“ nach „Cancelled“ von überall, oder „Escalate“ in jeder Phase.

Schalter „From Any Status“

Sie können jeden spezifischen Übergang im visuellen Editor in einen globalen umwandeln. Klicken Sie auf eine Übergangskante, öffnen Sie das Seitenpanel und aktivieren Sie „From any status“. Die Quelle wird auf „Any Status“ gesetzt und die Kante gestrichelt — erreichbar von allen Status. Deaktivieren stellt die ursprüngliche Quelle wieder her.

Besonders nützlich, wenn Sie merken, dass „Cancel“ oder „Close“ von jeder Phase aus verfügbar sein soll — ohne manuell Kanten von jedem Status zu ziehen.

hinweis

Benutzer können einen Statuswert immer leeren (auf leer setzen), unabhängig von Workflow-Regeln. Das ist beabsichtigt: Leeren zählt nicht als Übergang und wird nie blockiert.

Hat die Zeile noch keinen Status (erste Zuweisung nach Erstellung), kann jeder erlaubte Status frei gesetzt werden. Workflow-Validierung greift nur beim Wechsel von einem definierten Status zu einem anderen.

Bedingungen — Wer einen Übergang ausführen darf

Bedingungen steuern, welche Benutzer einen Übergang auslösen dürfen. Alle Bedingungen an einem Übergang nutzen AND-Logik — der Benutzer muss jede Bedingung erfüllen.

Bedingungstyp	Beschreibung
Role	Der Benutzer muss eine der angegebenen Board-Rollen halten.
User	Der Benutzer muss in einer Liste benannter Personen stehen.
Team	Der Benutzer muss einem der angegebenen Workspace-Teams angehören.
Row Owner	Nur der Ersteller der Zeile kann diesen Übergang auslösen.
Assignee	Nur aktuell der Zeile zugewiesene Benutzer (in einer Users-Spalte) können ihn auslösen.

hinweis

Board-Admins umgehen Bedingungsprüfungen — sie können jeden Übergang auslösen. Admins sind jedoch nicht von Validatoren befreit. Datenanforderungen gelten für alle.

Validatoren — Was wahr sein muss

Validatoren prüfen, ob die Zeilendaten Anforderungen erfüllen, bevor der Übergang fortgesetzt wird. Anders als Bedingungen gelten Validatoren für alle Benutzer, inklusive Admins.

Validator-Typ	Beschreibung
Field Required / Field Not Empty	Eine angegebene Spalte muss einen Wert haben. Ist sie leer, wird der Übergang blockiert.
Field Matches	Der Spaltenwert muss einem von Ihnen definierten Muster entsprechen. Nützlich für Referenznummern oder Codes.

Jeder Validator kann eine benutzerdefinierte Fehlermeldung anzeigen, damit Benutzer genau wissen, was vor dem Übergang ausgefüllt werden muss.

Pflichtfelder

Über Validatoren hinaus (die bestehende Daten prüfen) kann ein Übergang Benutzer auch auffordern, Felder im Moment des Übergangs auszufüllen. Sind Pflichtfelder konfiguriert, erscheint ein Dialog, sobald der Übergang ausgelöst wird, und fragt die Werte ab, bevor die Statusänderung abgeschlossen wird.

Nützlich, wenn Sie Kontext in einer bestimmten Phase erfassen wollen — z. B. „Rejection Reason“ beim Wechsel zu „Rejected“.

Was in Kanban passiert

Ziehen Sie eine Karte in der Kanban-Ansicht in eine neue Spalte und hat dieser Übergang Pflichtfelder, bewegt sich die Karte visuell und der Übergangsdialog öffnet sich sofort, um die fehlenden Werte zu erfassen. Die Statusänderung wird finalisiert, sobald Sie den Dialog ausfüllen und bestätigen.

Das ist beabsichtigt --- reibungsloses Drag-and-drop statt Blockade mitten im Ziehen, und die Abfrage stellt sicher, dass die Information vor dem Commit erfasst wird. Schließen Sie den Dialog ohne Abschluss, kehrt die Karte in die Originalspalte zurück. (Ist ein Übergang gar nicht erlaubt, wird das Ziehen einfach nicht akzeptiert und die Karte schnappt zurück.)

Gut zu wissen

Die Pflichtfeld-Abfrage ist Teil der Copera-Oberfläche --- sie erscheint, wenn Sie den Übergang über die App auslösen, und führt Sie zum richtigen Zeitpunkt zu den richtigen Details.

Brauchen Sie die harte Garantie, dass ein Feld für einen Übergang nie leer bleiben kann (unabhängig vom Änderungspfad), fügen Sie einen Validator vom Typ Field Required oder Field Not Empty hinzu oder markieren Sie das Feld als Required im pro-Status-Feldverhalten. Validatoren und pro-Status-Pflichtregeln gelten für alle, inklusive Board-Admins, und sind das richtige Werkzeug bei strikter Datenintegrität statt hilfreicher Abfrage.

Freigabe-Gates

Übergänge können die Freigabe benannter Personen erfordern, bevor die Statusänderung greift. Löst ein Benutzer einen Übergang mit Freigabe aus, wechselt die Zeile in den Status Pending Approval, während die Anfrage verarbeitet wird. Nach Beschluss (genehmigt oder abgelehnt) wechselt die Zeile zum Zielstatus oder zurück zum Originalstatus.

Freigeber-Typen

Freigeber auf vier Arten:

• Specific Users — Benannte Personen, die die Anfrage prüfen müssen.
• Board Role — Jeder mit einer angegebenen Board-Rolle (z. B. „Manager“) wird Freigeber.
• Row Owner — Der Ersteller der Zeile ist Freigeber.
• Column Based — Freigeber werden dynamisch aus einem Spaltenwert der Zeile bestimmt (siehe unten).

Spaltenbasierte bedingte Freigeber

Spaltenbasierte Freigabe leitet Anfragen an unterschiedliche Personen je nach Zeilenwert — ohne getrennte Übergänge oder Workflows pro Fall.

Bei Column Based erscheinen drei Optionen:

1. Condition column — Eine Dropdown-(SELECT-)Spalte der Tabelle. Der aktuelle Wert bestimmt die Freigeber.
2. Mapping table — Pro Option der Spalte einen oder mehrere Freigeber zuweisen. Beispiel: „Department“ mit RH, Systems, Finance — jeweils dem zuständigen Manager zuordnen.
3. Fallback approvers — Optionale Benutzer, wenn der Spaltenwert keinem Mapping entspricht (oder leer ist).

Beispiel — Mehrstufige Abteilungsfreigabe:

Angenommen, „Department“ hat RH, Systems und Finance. Zwei Übergänge:

• Open → In Review: Spaltenbasierte Freigabe auf „Department“ — RH → Manager A, Systems → Manager B
• In Review → Done: Spaltenbasierte Freigabe auf „Department“ — RH → Director X, Systems → Director Y

Jeder Übergang löst den passenden Freigeber für die Abteilung der Zeile auf. So entsteht mehrstufige Freigabe: zuerst Abteilungsmanager, dann Direktoren.

tipp

Der Anfragende (wer den Übergang ausgelöst hat) wird automatisch von der Freigeberliste ausgeschlossen, auch wenn er dem Mapping entspricht. Niemand genehmigt die eigene Anfrage.

Freigabe-Richtlinien

Richtlinie	Verhalten
ANY_ONE	Der erste Freigeber, der handelt (genehmigt oder ablehnt), löst die Anfrage für alle.
ALL	Jeder designierte Freigeber muss genehmigen. Eine Ablehnung lehnt die gesamte Anfrage ab.

Pending-Approval-Status

Bei aktivierter Freigabe an einem Übergang erstellt das System automatisch eine Statusoption Pending Approval an der Spalte. Das ist ein echter Status — kein versteckter interner Zustand — und funktioniert nahtlos mit jedem Copera-Feature:

• Filter: Tabelle filtern auf Zeilen, die auf Freigabe warten.
• Kanban-Ansicht: Eine Spalte „Pending Approval“ erscheint automatisch.
• SLA-Timer: Bedingungen so konfigurieren, dass die Zeit beim Betreten des Pending-Status startet und beim Verlassen pausiert.
• Automatisierungen: Auslösen, wenn der Status zu „Pending Approval“ wechselt (z. B. Reviewer auto-zuweisen oder Benachrichtigung senden).
• Pro-Status-Sichtbarkeit und Feldregeln: Overrides speziell für den Pending-Zustand.

Der Pending-Status erscheint im visuellen Editor als eigener Knoten mit amber Rahmen und Sanduhr-Symbol.

hinweis

Pending-Approval-Status werden vom System verwaltet. Sie können nicht manuell umbenannt oder gelöscht werden — sie entstehen, wenn Sie Freigabe an einem Übergang aktivieren, und werden bereinigt, wenn Sie sie deaktivieren.

So läuft der Flow:

1. Ein Benutzer löst einen Übergang mit Freigabe aus (z. B. Open → In Review).
2. Die Zeile wechselt sofort zu Pending Approval.
3. Die designierten Freigeber erhalten eine Benachrichtigung.
4. Bei Genehmigung: Wechsel zum Zielstatus (In Review).
5. Bei Ablehnung: Wechsel zum konfigurierten Ablehnungsstatus oder zurück zum Originalstatus (Open), falls keiner gesetzt ist.

Bei mehreren Übergängen mit Freigabe erhält jeder seinen eigenen Pending-Status (z. B. „Pending: Manager Approval“ und „Pending: Director Approval“).

Ablehnungsbehandlung

Bei Ablehnung eines Übergangs:

• Zur einem bestimmten Status wechseln (z. B. „Rejected“ oder „Needs Revision“).
• Ohne Ablehnungsstatus: zurück zum Status vor der Freigabe-Anfrage.

Benachrichtigungen

Anfragende und Freigeber erhalten In-App- und E-Mail-Benachrichtigungen. Freigeber bei neuer Anfrage; Anfragende bei Genehmigung oder Ablehnung.

Kommentare zu Freigabeentscheidungen

Freigeber können einen Kommentar zur Entscheidung hinzufügen. Sie können einen Kommentar bei Ablehnung erzwingen, damit Feedback immer dokumentiert ist.

hinweis

Pro Zeile und Status-Spalte kann nur eine Freigabe-Anfrage gleichzeitig pending sein. Solange eine Anfrage offen ist, kann kein neuer Übergang ausgelöst werden, bis sie gelöst oder abgebrochen ist.

Post-Transition-Funktionen

Post-Transition-Funktionen sind Aktionen, die nach erfolgreichem Übergang automatisch laufen (inkl. nach erteilter Freigabe). Sie laufen ohne Benutzerinteraktion.

Funktion	Beschreibung
Set Field	Spalte auf einen statischen Wert setzen.
Copy Field	Wert von einer Spalte in eine andere derselben Zeile kopieren.
Set Current Date	Aktuelles Datum und Uhrzeit in eine Datumsspalte schreiben — nützlich zum Zeitstempeln des Übergangs.
Assign Current User	Den Benutzer, der den Übergang ausgelöst hat, einer Users-Spalte hinzufügen.
Assign User	Eine oder mehrere bestimmte Personen einer Users-Spalte hinzufügen.
Clear Field	Wert einer Spalte vollständig entfernen.
Send Notification	In-App-Benachrichtigung an bestimmte Benutzer mit benutzerdefinierter Nachricht.
Webhook	HTTP-Request (POST, PUT oder PATCH) an eine externe URL senden.

Mehrere Post-Funktionen pro Übergang sind möglich; sie laufen in der aufgeführten Reihenfolge.

Pro-Status-Sichtbarkeit

Sie steuern, welche Benutzer Zeilen basierend auf dem aktuellen Status sehen dürfen. Konfiguration über Klick auf einen Statusknoten im visuellen Editor und dessen Einstellungspanel.

Sichtbarkeitseinstellung	Beschreibung
Role-based	Nur Benutzer mit bestimmten Board-Rollen sehen Zeilen in diesem Status.
User-based	Nur bestimmte benannte Benutzer sehen Zeilen in diesem Status.
Owner Can View	Der Ersteller sieht seine Zeilen immer, auch wenn Sichtbarkeitsregeln sie sonst ausschließen. Standardmäßig aktiv.
Assignee Can View	Der Zeile zugewiesene Benutzer sehen sie immer. Standardmäßig aktiv.

hinweis

Board-Admins sehen immer alle Zeilen, unabhängig von Sichtbarkeitsregeln. Sichtbarkeit gilt nur für reguläre Mitglieder und Gäste.

Pro-Status-Feldverhalten

Wenn eine Zeile in einem bestimmten Status ist, können Sie das Verhalten einzelner Felder überschreiben. Ebenfalls im Statusknoten-Panel.

Verhalten	Beschreibung
Editable	Normal — Feld lesbar und änderbar. Standard.
Read-only	Sichtbar, aber nicht editierbar. Admins können read-only Felder weiterhin bearbeiten.
Required	Feld muss einen Wert haben. Gilt für alle inkl. Admins — Datenintegritätsregel, keine reine Berechtigung.
Hidden	Für Nicht-Admins unsichtbar und aus API-Antworten ausgeschlossen. Admins sehen und bearbeiten weiterhin.

SLA-Timer

Workflow-Statusübergänge können SLA-Timer-Spalten automatisch starten, pausieren und stoppen. Wechselt eine Zeile in oder aus bestimmten Status, reagiert der Timer — für automatisches Tracking, wie lange Arbeit in jeder Phase verbringt. Details auf der Seite SLA-Tracking.

Tipps

• Einfach starten. Workflow zuerst mit wenigen Basis-Übergängen aktivieren, dann Bedingungen, Validatoren und Freigabe-Gates nachreifen lassen.
• Visuellen Editor nutzen, um den Prozess zu mappen. Flow auf der Canvas zeichnen, bevor Regeln hinzukommen — Lücken und Schleifen sind so leichter sichtbar.
• Globale Übergänge sind ideal für Ausnahmen. „Cancel“, „Escalate“ oder „Emergency Close“, die von jedem Status aus verfügbar sein sollen, funktionieren perfekt als globale Übergänge (from ANY).
• Freigabe-Gates mit pro-Status-Sichtbarkeit kombinieren. Zeile in „Pending Review“ legen, den nur Reviewer sehen, und Freigabe verlangen, bevor es weitergeht. Sicherer, auditierbarer Review-Prozess.
• Post-Funktionen für wiederkehrende Updates nutzen. Abschlüsse automatisch zeitstempeln, die Person zuweisen, die ein Ticket geschlossen hat, temporäre Felder leeren — ohne dass es jemand manuell merken muss.
• Mit einer Beispielzeile testen. Vor dem Rollout an das volle Team den Prozess mit einer Testzeile durchgehen und jeden Übergang, jede Bedingung und Freigabe prüfen.

Nächste Schritte

• Automatisierungen für eventgetriebene „wenn dies, dann das“-Regeln, die Workflow-Übergänge ergänzen.
• Board-Berechtigungen, um zu verstehen, wie Board-Rollen mit Workflow-Bedingungen zusammenspielen.
• Feldtypen, um zu verstehen, welche Spaltentypen mit Validatoren und Post-Funktionen arbeiten.