Ihre Service Cloud läuft. Cases kommen rein, das Team arbeitet sie ab, der Monatsbericht sieht ordentlich aus. Genau das ist das Problem. In gewachsenen Service-Orgs steckt Technik, für die Salesforce keinen Support mehr leistet, und niemand merkt es, solange nichts passiert.
Das Risiko ist nicht der Totalausfall morgen früh. Das Risiko ist der Fehler, den niemand mehr beheben kann, und zwar genau dann, wenn Kunden warten. Dieser Artikel zeigt die fünf Altlasten, die ich in Service-Cloud-Orgs im Mittelstand am häufigsten finde, und in welcher Reihenfolge Sie sie angehen.
Warum Ihre Service Cloud älter ist, als sie aussieht
Service-Orgs wachsen in Schichten. Jeder Admin, jede Agentur und jedes Projekt hat etwas hinzugefügt, kaum jemand hat etwas entfernt. Salesforce liefert dreimal im Jahr ein Release. Was 2017 Best Practice war, ist heute abgekündigt, und die Konfiguration von damals läuft einfach weiter.
Wie weit das gehen kann, habe ich bei einem Org-Audit im gehobenen Mittelstand gesehen: 94 Apex-Klassen, 10 Trigger und drei Batch-Jobs, die seit Jahren still scheiterten. Niemand hatte es bemerkt, weil kein Fehler bei einem Menschen ankam. Wie ich solche Audits aufbaue, beschreibe ich in meiner Methodik für den Salesforce Org Health Check.
Die folgenden fünf Punkte sind ein Ausschnitt davon, zugeschnitten auf den Kundenservice. Zwei davon haben einen offiziellen Stichtag, der schon hinter uns liegt. Drei sind meine Einschätzung aus der Praxis, ohne Abschaltdatum.
Altlast 1: Legacy Chat läuft seit dem 14.02.2026 ohne Support
Salesforce hat den Support für den alten Chat (Live Agent, Salesforce Chat, Embedded Chat) am 14. Februar 2026 beendet. Seitdem wird er ohne Gewährleistung und ohne SLA bereitgestellt. Der Nachfolger heißt Enhanced Chat und baut auf Messaging for In-App and Web auf. Das ist kein Update, sondern ein anderes Produkt: neue Bereitstellung, neues Snippet auf der Website, Routing über Omni-Channel.
Ob Ihr Service noch am alten Chat hängt, sehen Sie an den Transkripten. Entstehen weiter neue Datensätze im Objekt LiveChatTranscript, läuft ein Kundenkanal auf einem Produkt ohne Support. Die Abfrage läuft in der Developer Console:
SELECT COUNT() FROM LiveChatTranscript WHERE CreatedDate = LAST_N_DAYS:30Ist das Ergebnis größer als null, gehört der Chat ganz oben auf Ihre Liste. Ist es null, prüfen Sie trotzdem die Website. Ein altes Chat-Snippet, das niemand entfernt hat, ist ein Knopf, für den im Fehlerfall niemand mehr zuständig ist.
Altlast 2: Workflow Rules und Process Builder im Case-Prozess
Workflow Rules und Process Builder sind seit dem 31. Dezember 2025 ohne Support. Sie laufen weiter, aber Salesforce behebt keine Fehler mehr daran und hilft im Support-Fall nicht. Neue Workflow Rules lassen sich seit Winter '23 nicht mehr anlegen, neue Prozesse im Process Builder seit Summer '23.
Im Service stecken diese Automatisierungen fast immer an kritischen Stellen: Eingangsbestätigung an den Kunden, Eskalations-Feld nach Ablauf einer Frist, Benachrichtigung an den Case-Owner bei Statuswechsel. Also genau dort, wo ein Fehler sofort beim Kunden ankommt.
Einen Überblick gibt das Werkzeug Migrate to Flow im Setup. Wer es genauer will, fragt die aktiven Prozesse über die Tooling API ab (in der Developer Console das Häkchen Use Tooling API setzen):
SELECT Definition.DeveloperName, ProcessType, Status FROM Flow WHERE ProcessType = 'Workflow' AND Status = 'Active'Wie Sie die Migration sauber aufsetzen, steht im Artikel Process Builder und Workflow Rules zu Flows migrieren.
Altlast 3: E-Mail-to-Case mit altem Threading
E-Mail-to-Case ordnet Antworten über eine Kennung dem richtigen Case zu. Früher war das die Ref ID im Betreff oder im Text der Mail. Der Nachfolger ist Lightning Threading. Es nutzt ein sicheres Token in Betreff oder Text und greift ersatzweise auf die Mail-Header zurück. Die Ref ID ist bei Salesforce nur noch im Wartungsmodus: Neue Funktionen und Fehlerbehebungen gibt es ausschließlich für Lightning Threading.
Einen Stichtag gibt es hier nicht. Salesforce hat die ursprünglich geplante Erzwingung des Release Updates aufgegeben, der Umstieg bleibt freiwillig. Deshalb bleibt die Ref ID in vielen Orgs einfach stehen, bis ein Fehler auftaucht, den niemand mehr behebt.
Wie sich altes Threading im Alltag anfühlt, habe ich bei einem Premium-Optikhersteller gesehen: Mails, die aus SAP verschickt wurden, liefen nicht sauber in den bestehenden Case zurück. Das Ergebnis waren doppelte Cases für ein und dasselbe Anliegen. Doppelte Cases kosten doppelte Arbeit und verzerren jede Kennzahl zu Bearbeitungszeit und Erstlösungsquote.
Prüfen Sie deshalb nicht nur die Einstellung in Salesforce, sondern jedes System, das Mails im Namen Ihres Service verschickt: ERP, Ticket-Portal, Marketing-Tool.
Altlast 4: Routing über Zuweisungsregeln statt Omni-Channel
Für Case-Zuweisungsregeln gibt es kein Abschaltdatum. Sie funktionieren und werden weiter unterstützt. Trotzdem halte ich sie in den meisten Service-Teams ab einer gewissen Größe für eine Altlast.
Zuweisungsregeln legen einen Case in eine Queue. Wer ihn dort herausnimmt, entscheidet das Team selbst, und in der Praxis gewinnen die einfachen Fälle. Omni-Channel dagegen verteilt die Arbeit aktiv nach Kapazität und auf Wunsch nach Skills. Sie sehen, wer wie ausgelastet ist, und schwere Fälle bleiben nicht liegen.
Der eigentliche Grund liegt aber woanders: Enhanced Chat routet über Omni-Channel, und auch die Übergabe von einem KI-Agenten an einen Menschen läuft darüber. Wer Agentforce im Service plant, braucht also zuerst ein funktionierendes Omni-Channel. Was sich mit Agentforce gegenüber den alten Bots ändert, steht in Agentforce vs. Einstein Bots.
Altlast 5: SLAs, die nur im Handbuch stehen
Fast jeder Service im Mittelstand hat Zusagen: Erstreaktion in vier Stunden, Lösung in zwei Werktagen, Premium-Kunden zuerst. In vielen Orgs stehen diese Zusagen im Vertrag und im Onboarding-Dokument, aber nicht im System.
Salesforce bildet SLAs über Entitlements, Entitlement Processes und Milestones ab. Ein Milestone zeigt am Case, wie viel Zeit noch bleibt, und kann bei Überschreitung automatisch eskalieren. Ohne das erfahren Sie von einem gebrochenen SLA erst, wenn der Kunde sich beschwert.
Ein SLA, das nur im Vertrag steht, misst Ihr Kunde. Nicht Sie.
So priorisieren Sie: sofort, 2027, gar nicht
Nicht jede Altlast muss sofort weg. Die Reihenfolge ergibt sich aus zwei Fragen: Hat Salesforce die Technik abgekündigt, und kommt ein Fehler direkt beim Kunden an?
| Altlast | Status bei Salesforce | Priorität |
|---|---|---|
| Legacy Chat | Ohne Support seit 14.02.2026 | Sofort: Enhanced Chat einführen oder Chat bewusst streichen |
| Workflow Rules, Process Builder | Ohne Support seit 31.12.2025 | Sofort für alles mit Kundenkontakt, der Rest im Budget 2027 |
| E-Mail-Threading mit Ref ID | Wartungsmodus, Umstieg freiwillig | Budget 2027, mit Test aller Systeme, die Mails verschicken |
| Zuweisungsregeln statt Omni-Channel | Unterstützt, kein Stichtag | Budget 2027, sofern Chat oder Agentforce geplant sind |
| SLAs ohne Entitlements | Unterstützt, kein Stichtag | Budget 2027, wenn Sie SLAs vertraglich zusagen |
Und dann gibt es die Fälle, die Sie in Ruhe lassen sollten. Ein Team mit fünf Leuten und einer Queue braucht kein Omni-Channel mit Skills-Routing. Wer keine SLAs zusagt, braucht keine Milestones. Modernisieren um der Modernisierung willen kostet Budget und bringt nichts.
Für den ersten Überblick reichen 30 Minuten mit Ihrem Admin und diese fünf Fragen:
- Wann ist das letzte Chat-Transkript entstanden, und läuft auf der Website schon Enhanced Chat?
- Wie viele aktive Workflow Rules und Process Builder hängen am Case-Objekt?
- Mit welchem Threading arbeitet E-Mail-to-Case, und welche Systeme außer Salesforce schreiben an Kunden?
- Wie kommen Cases zu den Agents: per Zuweisungsregel in eine Queue oder über Omni-Channel?
- Welche SLAs sagen Sie zu, und wo im System sieht ein Agent, dass eines gleich reißt?
Häufige Fragen
Funktioniert Legacy Chat nach dem 14.02.2026 noch?
Salesforce hat den Support am 14.02.2026 beendet und stellt Legacy Chat seitdem ohne Gewährleistung und ohne SLA bereit. Ob und wie lange er technisch weiterläuft, sagt Salesforce nicht zu. Auf so etwas sollte kein Kundenkanal bauen.
Hören Workflow Rules seit dem 31.12.2025 auf zu laufen?
Nein. Bestehende Workflow Rules und Process Builder laufen weiter. Salesforce leistet dafür aber keinen Support mehr und behebt keine Fehler. Wenn etwas bricht, sind Sie auf sich gestellt.
Wie lange dauert eine Bestandsaufnahme der Service Cloud?
Die fünf Fragen oben beantwortet Ihr Admin in einer halben Stunde. Eine vollständige Inventur mit Migrationspfad und Aufwandsschätzung dauert in einer typischen Mittelstands-Org etwa vier Personentage.
Kann ich mit Agentforce die Altlasten einfach überspringen?
Nein. Ein KI-Agent im Service übergibt schwierige Fälle über Omni-Channel an Menschen und arbeitet auf Ihren Case-Daten. Unsaubere Automatisierung und fehlendes Routing werden durch KI nicht besser, sondern schneller sichtbar.
Wenn Sie wissen wollen, welche dieser Altlasten in Ihrer Service Cloud stecken, mache ich für Sie den Service-Cloud-Modernisierungs-Check. Vier Personentage zum Festpreis, danach haben Sie eine Inventur aller fünf Punkte, einen Modernisierungsplan mit Aufwand und Risiken und eine klare Reihenfolge für Ihr Budget 2027. Entscheiden Sie sich danach für die Umsetzung mit mir, rechne ich den Check voll an.
