Reopen- & Lifecycle-Governance

Reopen-Governance regelt einheitlich, ob, wie lange, durch wen und wie oft eine geschlossene Entität wieder geöffnet werden darf — über Ticket, Incident und Problem hinweg. Die Regeln sind für alle drei Entitätstypen gleich und je Typ in der Lifecycle-Config einstellbar. Dazu gehören Auto-Close (zeitgesteuertes Schließen gelöster Tickets), WC-Auto-Resolve (Auflösen unbeantworteter Waiting-Customer-Tickets), Stale-Reminder (Inaktivitäts-Eskalation über alle drei Domänen), Reopen-Eskalation (Qualitätssignal bei zu häufigem Wiederöffnen) und ein eigenes Analytics-Dashboard.

Ablauf eines Reopens

Ob wiedergeöffnet werden darf, entscheidet eine zentrale Prüfung anhand der Lifecycle-Config. Danach setzt das System die Abschlussfelder zurück (u. a. Resolution-Code, closedAt/resolvedAt), erhöht reopenCount und schreibt Timeline-Eintrag, Audit und Benachrichtigung.

Lifecycle-Config (je Entität, admin-editierbar)
        │  reopenEnabled · reopenWindowDays · reopenWindowMode · maxReopenCount
        │  reasonRequired · notifyOnReopen · slaOnReopenFrom{Resolved,Closed}
        │  autoCloseEnabled · autoResolveWaitingEnabled · staleReminderEnabled · reopenEscalationThreshold
        ▼
Reopen-Prüfung (Fenster, Limit, Grund, Genehmigung)        │  → erlaubt / abgelehnt mit Fehlercode        ▼
Zurücksetzen je Entitätstyp   Ticket
   Incident (+ Genehmigung)
   Problem
        │  reset closedAt/resolvedAt/resolutionCode · reopenCount++ · reopenedAt
        ▼
   Audit REOPENED · sichtbarer Timeline-Eintrag · Notification (*_REOPENED)

Reopen-Auswertung (Policy-Schritte)

Die Prüfung läuft in fester Reihenfolge ab. reopenOverride umgeht NUR Fenster und Limit — NICHT die Grund-Pflicht und NICHT die Approval-Pflicht (Incident). Auch ein Admin braucht einen Grund.

onWindowExpired (Ticket): Ist das Reopen-Fenster eines Tickets abgelaufen, erzeugt eine Kundenantwort per E-Mail ein neues, mit dem alten verknüpftes Ticket (originContext EMAIL_FOLLOWUP) statt eines Reopens — der Kunde wird nie ausgesperrt.

reopenWindowMode: Das Reopen-Fenster zählt wahlweise in Kalendertagen (CALENDAR, Default) oder Business-Tagen (BUSINESS). BUSINESS zählt nach den Geschäftszeiten der Standard-SLA-Policy des jeweiligen entityType; fehlt eine Default-Policy bzw. BusinessHours-Config, fällt es sicher auf CALENDAR zurück.

Verhalten je Domäne

Wichtig (Ticket): RESOLVED ist KEINE Reopen-Quelle — der Wechsel von RESOLVED zurück in einen aktiven Status ist ein normaler editStatus-Wechsel (kein Grund, kein Counter), damit die Reopen-KPI sauber bleibt. Reopen-Quellen sind ausschließlich CLOSED und SPAM. Ein Reopen eines gemergten Tickets wird auf das lebende Ziel-Ticket umgeleitet (mergedToTicketId).

Feature-Matrix je Domäne

Alle Lifecycle-Automationen (Auto-Close, WC-Auto-Resolve, Stale-Reminder, Reopen-Eskalation) sind per Default AUS und werden je Entität in der Lifecycle-Config aktiviert. Die zugehörigen Jobs laufen planmäßig, tun aber nichts, solange die Funktion nicht aktiviert ist.

Permissions

Reopen ist ein eigenes Recht; editStatus und editAll schließen es nicht ein. Eine Rolle mit editAll, aber ohne reopen, kann nicht wiederöffnen.

Die mitgelieferten Standardrollen sind so vorbelegt: Agent hat reopen, Admin hat reopen und reopenOverride, Endanwender und Genehmiger haben keines der beiden Rechte. Einer neu angelegten Rolle müssen beide Rechte ausdrücklich gegeben werden. Permissions & RBAC

Konfiguration (Admin)

Zwei Bereiche steuern die Governance — Admin-Center → Service-Konfiguration → Reopen & Lifecycle (/admin/lifecycle), Recht settings.editGeneral:

• Reopen-Gründe — CRUD je Entität (Label mehrsprachig, Notiz-Pflicht je Grund, Sortierung, Soft-Delete → 204). Fehler: doppelter Code 409 REOPEN_REASON_CODE_EXISTS; letzter aktiver Grund einer Entität 409 REOPEN_REASON_LAST_ACTIVE; unbekannte ID 404 REOPEN_REASON_NOT_FOUND. Inaktive Gründe mitzulesen (?includeInactive=true) erfordert settings.editGeneral; ein Entzug dieses Rechts wirkt sofort. GET/POST/PATCH/DELETE /api/reopen-reasons
• Lifecycle-Config — Fenster (Tage + Modus CALENDAR/BUSINESS), Maximalzahl, Grund-Pflicht je Rolle, notifyOnReopen, SLA-Verhalten bei Reopen (slaOnReopenFromResolved/Closed), Auto-Close, WC-Auto-Resolve, Stale-Reminder-Tiers, Eskalations-Schwelle. Die Settings-UI zeigt je Tab nur die für die Entität sinnvollen Felder (z.B. Auto-Close/WC-Auto-Resolve nur bei Ticket). GET /api/lifecycle-config · PUT /api/lifecycle-config/:entityType

Restlaufzeit des Reopen-Fensters: GET /api/lifecycle-config/:entityType/reopen-window liefert reopenEnabled/Days/From und braucht nur eine Anmeldung. Die Detail-Seitenleiste zeigt die Restlaufzeit an. Die vollständige Config erfordert settings.editGeneral.

Auto-Close

Auto-Close schließt fällige Tickets zeitgesteuert wie ein normaler Statuswechsel (closedAt, SLA und Verlauf werden gesetzt). Auto-Close gibt es nur für Tickets (autoCloseEnabled, standardmäßig aus). Incidents und Problems werden immer von Hand geschlossen, weil dort eine Genehmigung bzw. ein PIR den Abschluss bestimmt.

WC-Auto-Resolve (Waiting-Customer)

Als Vor-Stufe zu Auto-Close: Tickets im Status WAITING_CUSTOMER, auf die der Kunde nicht reagiert, werden nach einer konfigurierten Frist automatisch auf RESOLVED gesetzt (danach greift ggf. der normale Auto-Close-Pfad). Nur TICKET, opt-in.

Stale-Reminder (Inaktivität)

Inaktivitäts-Erinnerung für TICKET, PROBLEM und INCIDENT. Meldet zu lange unbewegte Vorgänge gestaffelt an Assignee (Stufe 1) → Gruppen-Lead (Stufe 2) → Manager (Stufe 3), jeweils nur an Personen mit Sicht auf den Vorgang. Ändert nie Status oder SLA.

• Job: lifecycle_stale_entity_reminder (täglich ~01:30)
• Config: staleReminderEnabled, staleReminderDaysTier1/2/3 (je Entität)
• Notification: TICKET_STALE_REMINDER / PROBLEM_STALE_REMINDER / INCIDENT_STALE_REMINDER
• Ausschlüsse: terminal + je Typ (Ticket: ON_HOLD/WAITING_CUSTOMER/SLA-paused/offener Incident-Link; Problem: ON_HOLD/WAITING_VENDOR; Incident: ON_HOLD/PENDING_CLOSURE)

Reopen-Eskalation

Wird eine Entität öfter als die konfigurierte Schwelle wiederöffnet (reopenCount ≥ reopenEscalationThreshold), werden die Verantwortlichen proaktiv alarmiert — ein Qualitätssignal. Empfänger sind der Assignee plus Gruppen-Lead/Manager, jeweils nur, wenn sie den Vorgang sehen dürfen (wie bei SLA- und Stale-Erinnerungen). Findet sich niemand Berechtigtes, läuft die Eskalation die Management-Kette hoch; findet sich auch dort niemand, wird der Audit-Eintrag REOPEN_ESCALATION_NO_RECIPIENT geschrieben.

• Job: lifecycle_reopen_escalation (täglich ~03:00)
• Schwelle: reopenEscalationThreshold (null = aus; opt-in je Entität)
• Dedup: reopenEscalatedCount — erneute Eskalation erst bei jedem weiteren Reopen über der Schwelle
• Notification: REOPEN_ESCALATION (intern, nicht customerFacing)

Notifications

Keine doppelte Benachrichtigung: Ein Reopen ist auch ein Statuswechsel. Empfänger erhalten dafür nur die Benachrichtigung *_REOPENED, nicht zusätzlich die allgemeine Statuswechsel-Benachrichtigung. Verlinkte Vorgänge werden über das Cascading-System informiert (LINKED_*_REOPENED). Cascading System

Felder & Analytics

Jede Entität trägt closedAt, reopenCount, reopenedAt und lastReopenReasonCode. Jeder Reopen erzeugt einen sichtbaren REOPENED-Timeline-Eintrag (Grund + Notiz) und ein Audit-Event. Daraus speist sich die Reopen-Analytik:

In der UI: das Lifecycle-Dashboard unter /lifecycle-analytics (Reporting-Navigation) mit Entity-Tabs, Zeitraum, Summary-Cards, Trend und Ranked-Breakdowns; zusätzlich ein kompaktes Widget zur Reopen-Rate auf dem Haupt-Dashboard.