Die Salesforce-Fallzusammenführung fasst bis zu drei doppelte Cases in einem Master-Case zusammen, und der Merge lässt sich nicht rückgängig machen. Admins schalten sie unter Setup ein, legen fest, ob Duplikate mit dem Status Merged behalten oder gelöscht werden, und fügen die Merge-Cases-Aktion sowie den Listenbutton hinzu. Verknüpfte Listen, Feed-Einträge und untergeordnete Datensätze wandern zum Master. Milestones, Case Share und Case Team tun das nicht, und Anhänge können verloren gehen. Prävention zählt mehr als Aufräumen: Die meisten Duplikate gehen auf E-Mail-Threading zurück. Ein KI-Teammitglied wie eesel kann das wahrscheinliche Original erkennen und eine Notiz hinterlassen, sodass ein Mitarbeiter mit dem Kontext, der schon vorliegt, zusammenführt.
Ich arbeite in der eesel-Support-Queue, deshalb sind Duplikate für mich eine tägliche Nervensache und kein abstraktes Datenqualitätsthema. Jeder zweite Case zum selben Problem teilt die Historie eines Kunden auf zwei Datensätze auf und schickt zwei Leute los, um eine Frage zu beantworten. Für diesen Guide habe ich Salesforces Merge- und E-Mail-Threading-Dokumentation von vorne bis hinten gelesen. Mit der eesel CLI kann ein Coding-Agent eine freigegebene Merge- und Duplikat-Richtlinie als Wissen hochladen und dann Testfragen stellen, um die Antworten zu prüfen, bevor etwas live geht. Die Salesforce-Org selbst zu verbinden, braucht weiterhin jemanden mit Admin-Rechten, der das genehmigt.
Was macht die Salesforce-Fallzusammenführung eigentlich?
Sie fasst bis zu drei Cases in einem zusammen und behält den, den du als Master wählst. Salesforces Merge-Artikel sagt, dass du Feldwerte vergleichst, die gewünschten für den Master auswählst, und dass „alle verknüpften Listen, Feed-Einträge und untergeordneten Datensätze dem Master hinzugefügt werden".
Was mit den anderen Cases passiert, ist eine Admin-Entscheidung. Ist die Org auf Duplikate löschen eingestellt, werden sie soft gelöscht und liegen 15 Tage im Papierkorb. Behält sie sie, wird dem Betreff im Highlights-Panel das Wort „Merged" angehängt, und ein Link auf dem Duplikat führt zum primären Case.
Salesforce führt das nach wie vor unter Service Cloud, aber der neuere Produktname ist Agentforce Service. Das Case-Objekt und das Merge-Feature sind dasselbe, such also nach beiden Namen, wenn du Docs suchst. Bist du neu beim Objekt selbst, behandelt mein Salesforce Ticketsystem-Guide, wie Cases ankommen und sich bewegen.
Wie führt man doppelte Cases Schritt für Schritt zusammen?
Es gibt drei Einstiegspunkte, und bei allen ist die Auswahl auf drei Cases begrenzt. Salesforce dokumentiert jeden davon auf derselben Merge-Seite:
- Aus der Cases-Listenansicht. Wähle bis zu drei Cases aus, klicke auf Merge Cases, wähle den Master im Compare-Cases-Fenster, lege die Feldwerte fest und klicke dann auf Next und Merge.
- Vom Case-Datensatz aus. Öffne den Case, nutze das Menü im Highlights-Panel, klicke auf Merge Cases und suche nach den Cases, die zusammengeführt werden sollen. Das ist der richtige Weg, wenn das Duplikat nicht in deiner aktuellen Listenansicht steht.
- Von einer verknüpften Liste auf einem beliebigen Standardobjekt. Öffne einen Account, wähle View All im Cases-Panel, wähle bis zu drei Cases aus und klicke auf Merge Cases.
Mitarbeiter brauchen Read, Create, Edit und Delete auf Cases, laut der Berechtigungstabelle auf dieser Seite. Fehlt der Button, ist der erste Verdächtige das Admin-Setup unten, nicht das Profil des Mitarbeiters.
Wie richtet man die Fallzusammenführung in Lightning ein?
Schalte die Einstellung ein, lege fest, was mit Duplikaten passiert, und platziere die Aktion dort, wo Mitarbeiter sie finden. Salesforces Setup-Artikel sagt, dass du sowohl Manage Cases als auch Customize Application brauchst, dann:
- Gib in Setup
Case Mergein die Quick Find ein und wähle Case Merge. - Schalte Merge Cases um, um zu den Einstellungen zu kommen.
- Wähle Delete duplicate cases after merge, oder behalte sie und weise einen Status aus der Merged Case Status-Pickliste zu (oder füge mit Add a Case Status einen eigenen hinzu).
- Füge die Merge Cases-Aktion zur Case-Datensatzseite und den Merge Cases-Button zur Listenansicht hinzu.
- Optional kannst du über Object Manager wie bei jeder anderen verknüpften Liste eine Merged Cases-Liste zum Case-Layout hinzufügen.
In diesem Screenshot ist die Keep-Option als empfohlen markiert. Da stimme ich zu: Behalte die Duplikate mit dem Status Merged, bis du deinem Prozess vertraust. Gelöschte Duplikate verlassen den Papierkorb nach 15 Tagen, und da sich ein Merge nicht rückgängig machen lässt, ist ein behaltenes Duplikat die einzige Prüfspur, die du hast, falls ein Mitarbeiter den falschen Master gewählt hat.
Was geht bei einem Merge verloren oder bleibt zurück?
Einiges davon ist dokumentiert, und manches übersieht man leicht. Der Setup-Artikel listet diese Einschränkungen auf:
| Einschränkung | Was das für dich bedeutet |
|---|---|
| Ein Merge lässt sich nicht rückgängig machen | Prüfe Master und Feldauswahl auf dem Vergleichsbildschirm, bevor du auf Merge klickst |
| Case Milestones, Case Share und Case Team werden nicht zusammengeführt | Der Master behält nur seine eigene SLA-Uhr und sein eigenes Team |
| Anhänge werden nicht unterstützt und können gelöscht werden | Sichere zuerst jede Datei, die du vom Duplikat brauchst |
| Das Compare-Cases-Fenster zeigt nur die ersten 35 Lookup-Felder im Layout | Ein Lookup darüber hinaus lässt sich beim Merge nicht auswählen |
| Actions und Recommendations auf dem primären Case werden verdoppelt | Rechne nach einem Merge mit doppelten Vorschlägen |
| Cases, die in einer Omni-Channel-Warteschlange anstehen oder mit dem Status Opened oder Assigned zugewiesen sind, lassen sich nicht zusammenführen | Siehe den Omni-Channel-Abschnitt unten |
Zwei davon ändern, wie ich einen Master wählen würde. Weil Milestones nicht mitwandern, wähle den Case, dessen Entitlement und SLA-Uhr die echten sind, meist der älteste. Mein Guide zu Entitlements und Milestones erklärt, warum ein Case ohne Entitlement überhaupt keine Uhr bekommt. Und weil Anhänge gefährdet sind, behandle den Merge als den Moment, Dateien von Hand zu verschieben. Ein zusammengeführter Case kann mit einem langen Feed enden, deshalb helfen KI-Case-Zusammenfassungen dem nächsten Mitarbeiter, schnell aufzuholen.
Ein E-Mail-Detail ist auch wichtig. Salesforces Threading-Hinweise sagen, dass nach dem Zusammenführen zweier Cases alle weiteren eingehenden E-Mails am Parent-Case hängen, selbst wenn sie zum Child gehörten, und dass der Mitarbeiter, der zusammenführt, entscheidet, welcher Case der Parent ist.
Kann man einen Case zusammenführen, der in einer Omni-Channel-Warteschlange wartet?
Standardmäßig nein, und eine Beta-Einstellung ändert das für noch nicht geöffnete Cases. Die Standardeinschränkung blockiert Duplikate, die in einer Omni-Channel-Warteschlange anstehen oder Mitarbeitern mit dem Status Opened oder Assigned zugewiesen sind. Salesforces Beta-Artikel fügt im Case-Merge-Setup eine Checkbox hinzu, die Cases mit Pending Routing und Assigned erlaubt und Opened weiterhin blockiert.
Lässt sich dieses Duplikat zusammenführen?
Wähle die Beta-Einstellung und wo das Duplikat in Omni-Channel steht. Die Antwort folgt Salesforces dokumentierten Regeln.
Der Grund für diese Grenze ist der Routing-Lebenszyklus. Sobald ein Mitarbeiter ein Arbeitselement annimmt, ist der Case in Bearbeitung, und ein Merge durch jemand anderen könnte die Sitzung dieses Mitarbeiters überschreiben. Der Fehler lautet „We couldn't merge these cases. One or more of the duplicate cases is currently being worked on", und die Lösung ist, dass der Mitarbeiter den Tab schließt oder das Arbeitselement freigibt. Salesforce führt das Feature als Beta unter seinen Beta Services Terms, deshalb würde ich es zuerst in einer Sandbox testen. Mein Omni-Channel-Routing-Guide behandelt die Pending-Routing- und Assignment-Datensätze hinter diesen Status.
Woher kommen doppelte Cases?
Meistens aus E-Mails, die keinem bestehenden Case zugeordnet werden können. Salesforces Email-to-Case-Threading-Seite erklärt die Reihenfolge des Abgleichs. Unter Lightning Threading wird eine eingehende E-Mail zuerst über ein 23-stelliges Token im Betreff oder Text abgeglichen. Schlägt das fehl, prüft Salesforce die Header In-Reply-To, References und Thread-Index. Schlagen beide fehl, legt es einen neuen Case an.
Die Seite zu den Einschränkungen nennt die Wege, auf denen der Abgleich scheitert:
- Ein Kunde bearbeitet den Betreff. Je nach E-Mail-Client kann das Ändern des Betreffs das Threading-Token entfernen und einen neuen Case verursachen.
- Mehr als eine Routing-Adresse. Salesforce rät, Kunden zu bitten, nur an eine Adresse zu schreiben, und sagt, dass das Senden an mehrere zu unerwarteten Ergebnissen führt und nicht unterstützt wird.
- Relays und Mailserver, die Header verändern. Ein Relay, das die Salesforce-Message-ID ändert, muss die ursprüngliche in den References-Header verschieben, und ein eigener Mail Transfer Agent, der References oder In-Reply-To entfernt, kann neue Cases verursachen.
- Altes Ref-ID-Threading. Ohne Lightning- oder Header-basiertes Threading erzeugt eine Antwort ohne ihre Ref ID einen neuen Case. Salesforce bezeichnet Ref-ID-Threading als reinen Wartungsmodus und empfiehlt den Wechsel.
- Eine aktualisierte Sandbox. Ändert sich die Org-ID, funktioniert das an die alte Org-ID gebundene Token nicht mehr.
Threading deckt E-Mail ab. Für Webformulare und Messaging-Kanäle habe ich in den gelesenen Salesforce-Docs keinen vergleichbaren Abgleichmechanismus gefunden, deshalb würde ich annehmen, dass ein Kunde, der zweimal absendet oder eine zweite Sitzung startet, mit einem zweiten Case enden kann. Prüfe das an deiner eigenen Org, bevor du dich darauf verlässt. Kommen Duplikate davon, dass mehrere Leute ein Postfach beobachten, ist Ticket-Swarming ein verwandtes Problem. Wo diese Kanäle landen, zeigt mein Guide zu Enhanced Messaging.
Kann Salesforce Duplikate vorschlagen, bevor Mitarbeiter sie finden?
Ja, in einer Beta namens Enhanced Case Merge. Salesforces Artikel zu Enhanced Case Merge beschreibt den Übergang „von manueller, reaktiver Aufräumarbeit zu proaktiver Prävention" in drei Schritten:
- Setze im Case-Merge-Setup das Häkchen bei Merge cases with Enhanced Case Merge.
- Gib unter Duplicate Rules jeder Regel einen Namen, wähle eine Matching Rule, die festlegt, wie Duplikate erkannt werden, und lege die Bedingungen fest, die ein Case erfüllen muss, bevor die Regel läuft.
- Ziehe die Komponente Duplicate Cases im Lightning App Builder auf die Case-Datensatzseite.
Die Komponente listet dann wahrscheinliche Duplikate mit Case-Nummer, Betreff, Kontakt und Öffnungsdatum, plus einen Button, der das Merge-Fenster mit dem aktuellen Case als vorausgewähltem Primärfall öffnet. Es ist eine Beta, also gilt derselbe Sandbox-zuerst-Rat. Außerdem bleibt der Merge weiterhin bei einem Menschen, und dort würde ich ihn auch lassen.
Wie kann KI doppelte Cases reduzieren?
Indem sie schneller antwortet und auf das Original hinweist, nicht indem sie selbst zusammenführt. Ein Merge lässt sich nicht rückgängig machen, deshalb würde ich einen Agenten nie unbeaufsichtigt einen durchführen lassen. Was ein Agent sicher tun kann, ist den neuen Case zu lesen, eure anderen Cases zu durchsuchen und eine private Notiz zu hinterlassen, etwa „das sieht aus wie der Case, der heute Morgen vom selben Kontakt eröffnet wurde". eesels Salesforce-Integration arbeitet so innerhalb der Org: Sie liest Cases und Knowledge-Artikel, entwirft Antworten als interne Case-Kommentare und kann zuerst den Account nachschlagen und andere Cases durchsuchen, laut ihren Docs. Euer Agent sieht nur das, was der autorisierte Salesforce-Nutzer sehen kann, sodass Objekt- und Feldberechtigungen die eigentliche Grenze bleiben.
Diese Grenze passt zu jedem KI-Governance-Review, das ihr schon durchführt. Salesforces eigene KI-Einschränkungen sind lesenswert, bevor du eine Ebene wählst.
Zwei Kundengeschichten zeigen das Muster auf anderen Helpdesks. Rúngne betreibt drei Agenten auf Gorgias, wo sich E-Mail, Chat und Social-Kommentare eine Warteschlange teilen. In einem Monat bearbeiteten seine Agenten etwa 2.100 Tickets, taggten etwa 880, hinterließen etwa 580 Antwortentwürfe als interne Notizen und beantworteten etwa jedes siebte Ticket direkt. Rauschen wie Werbekommentare, Abwesenheitsantworten und Spam wird getaggt und geschlossen, sodass es nie zu einem zweiten Datensatz wird, den man aufräumen muss, eine Aufgabe näher an Ticket-Klassifizierung als am Zusammenführen. Bei SamCart schickt ein Freshdesk-Agent die erste Antwort nur, wenn noch kein Teammitglied zugewiesen ist. Meine Lesart: Eine schnelle erste Antwort reduziert die „Gibt's was Neues?"-Nachfragen, aus denen so oft Duplikate werden, auch wenn keine der beiden Geschichten Duplikate direkt misst.
Für schnellere Antworten, sieh dir meinen Guide zur Automatisierung der Erstantwort an. Für insgesamt weniger Tickets, sieh dir Ticket-Vermeidung an.
Für dieselbe Idee auf anderen Stacks, sieh dir meinen Guide zur Ticket-Deduplizierung an. Freshdesks Version dieser Aufgabe steht im Artikel zum Zusammenführen von Freshdesk-Tickets.
Ist deine Warteschlange schon verrauscht, bevor sie dupliziert, starte mit Spam-Filterung. Mein Shared-Inbox-Vergleich behandelt die Eingangsseite.
Was würde ich zuerst einrichten?
Zuerst vorbeugen, dann das Aufräumen sicher machen. Das ist die Reihenfolge, die ich auf einer Service-Cloud-Org verwenden würde:
- Prüfe deine Threading-Methode. Zeigt Setup Einstellungen für „Insert thread ID", bist du auf Ref-ID-Threading. Wechsle zu Lightning Threading und aktiviere sowohl die Token- als auch die Header-Option.
- Reduziere Routing-Adressen. Eine Adresse pro kundenseitigem Postfach, und sag Kunden, dass sie nicht mehrere in Kopie setzen sollen.
- Aktiviere Case Merge mit ausgewähltem Keep. Füge einen klaren Merged-Status, die Aktion, den Listenbutton und die verknüpfte Liste Merged Cases hinzu.
- Schreibe eine Master-Case-Regel. Meine lautet: ältester Case mit gültigem Entitlement, und Anhänge zuerst von Hand verschieben.
- Schule Mitarbeiter in der Omni-Channel-Regel. Cases mit dem Status Opened lassen sich nicht zusammenführen, gib das Arbeitselement also vor einem Merge frei.
- Teste Enhanced Case Merge in einer Sandbox. Starte mit einer eng gefassten Duplicate Rule.
- Füge eine KI-Notizebene hinzu. Lass einen Agenten wahrscheinliche Originale markieren, und behalte den Merge-Klick beim Mitarbeiter. Gib die wirklich schwierigen Fälle mit KI-Eskalation weiter.
Sorgst du dich, was Service Cloud kostet, wenn sich diese Add-ons summieren, behandelt meine Preisaufschlüsselung die Editionen. Was du sonst noch am Case-Objekt automatisieren kannst, zeigt Salesforce-Case-Automatisierung. Für den größeren Blick, starte mit Helpdesk-KI.
eesel für Salesforce Service Cloud testen
Fressen doppelte Cases die Zeit eurer Mitarbeiter, arbeitet eesel wie eine neue Kollegin, die sich in eure Service-Cloud-Org einklinkt, jeden neuen Case mit der Historie des Accounts liest und einen Entwurf oder eine Notiz „possible duplicate of" als internen Kommentar hinterlässt. Eure Mitarbeiter behalten die Merge-Entscheidung, und euer Admin behält die Kontrolle darüber, was der Agent sehen kann. Kostenlos zum Testen.
