Ein Case ist erstellt, aber die Queue bleibt leer. In den allermeisten Fällen ist der Datensatz nicht verloren, sondern in einer Routing-Stufe hängengeblieben oder still in die Fallback-Queue umgeleitet worden. Unified Routing in Dynamics 365 Customer Service führt jeden Case durch vier klar definierte Stufen, und die leere Queue verrät nur das Symptom, nicht die Ursache. Dieser Artikel erklärt, wie die Routenführung arbeitet, warum Cases scheinbar verschwinden und wie Sie den Grund in wenigen Minuten eingrenzen.
Wie Unified Routing einen Case durch das System führt
Unified Routing ist die serverseitige Engine, die eingehende Arbeitselemente automatisch dem richtigen Workstream, der richtigen Queue und dem passenden Agenten zuordnet. Für Datensätze wie Cases läuft die Verarbeitung in vier aufeinander folgenden Stufen ab: Intake, Klassifizierung, Route-to-Queue und Zuweisung. Jede Stufe kann den Case weiterreichen, umleiten oder blockieren.
Intake: welcher Workstream übernimmt
Beim Record Routing wird zuerst die Intake-Regel geprüft. Sie entscheidet, welcher Workstream einen eingehenden Case übernimmt. Trifft keine Intake-Regel zu, startet die eigentliche Routenführung für diesen Case gar nicht. Wichtig ist eine Aussage direkt aus der Microsoft-Dokumentation: nach dem Aktivieren von Unified Routing leitet die aktive Basis-Routingregel so lange keine Datensätze, bis Sie Intake-Regeln konfiguriert haben. Den vollständigen Ablauf des Record Routing dokumentiert Microsoft Learn.
Klassifizierung und Route-to-Queue
Nach dem Intake durchläuft der Case die Work-Classification-Regelsätze, die Attribute wie Priorität, Skills oder Sprache anreichern. Danach greift der Route-to-Queue-Regelsatz, der nach dem Muster arbeitet: wenn Bedingung erfüllt, dann leite in diese Queue. Ein Workstream hat genau einen Route-to-Queue-Regelsatz, und die Reihenfolge der Regeln in der Entscheidungsliste ist entscheidend.
Zuweisung an einen Agenten
In der letzten Stufe versucht die Engine, den Case einem Agenten in der Queue zuzuweisen, basierend auf Kapazität, Präsenz und Skills. Scheitert die Zuweisung, bleibt der Case in der Queue liegen, obwohl das Routing eigentlich erfolgreich war.
Warum der Case nicht in der erwarteten Queue landet
Die leere Queue hat fast immer eine von wenigen Ursachen. Diese treten in der Praxis am häufigsten auf.
Unified Routing ist nicht provisioniert oder aktiv
Record Routing setzt voraus, dass Unified Routing im Environment provisioniert ist, dass die Case-Tabelle über die Datensatzkanäle für Queues aktiviert wurde und dass ein aktiver Workstream existiert. Fehlt einer dieser Bausteine, wird der Case nie in die Routing-Pipeline aufgenommen. Ein häufiger Sonderfall: Nach einem Upgrade mit installiertem Dynamics 365 Contact Center können alte Workstreams bestehen, die vor dem erneuten Provisionieren neu angelegt werden müssen.
Keine aktive Intake-Regel oder falsche Reihenfolge
Selbst bei aktivem Unified Routing bleibt die Queue leer, wenn keine Intake-Regel dem Workstream zugeordnet ist oder die Regeln in der falschen Reihenfolge stehen. Da die Auswertung nach dem First-Match-Prinzip läuft, kann eine zu breite Regel weiter oben eine speziellere Regel darunter abfangen. Der Case landet dann im falschen Workstream und damit in einer anderen Queue.
Ruleset-Bedingung greift nicht
Eine sehr verbreitete Falle sind Bedingungen, die zum Zeitpunkt der Case-Erstellung noch nicht zutreffen. Prüft eine Intake- oder Route-to-Queue-Regel etwa auf Priorität gleich Hoch, ein neuer Case aber ohne gesetzte Priorität ankommt, matcht die Regel nicht. Ein reales Beispiel aus der Community: Das Intake-Routing sollte nur Cases mit hoher Priorität weiterreichen, die Bedingung war aber so gebaut, dass gar kein Case die nächste Stufe erreichte.
Case wird erst nach einem Statuswechsel geroutet
Ob ein Case sofort bei der Erstellung oder erst nach einem Status- oder Feldwechsel geroutet wird, hängt von der Konfiguration ab. Setzt eine Automatisierung oder ein Agent das entscheidende Feld erst nachträglich, taucht der Case auch erst dann in der Queue auf. Wer die Wechselwirkungen mehrerer Regeln beim Case-Routing sauber trennen will, findet Anregungen im Beitrag zu Case-Routing-Konflikten.
Fallback-Queue schluckt den Case
Wenn keine Route-to-Queue-Regel definiert ist, keine Regel zutrifft oder während der Klassifizierung ein Fehler auftritt, leitet Unified Routing den Case in die Fallback-Queue des Workstreams. Der Case ist also da, nur eben nicht in der erwarteten Queue. Das Detail dazu steht bei Microsoft Learn zu Route-to-Queue-Regeln. Prüfen Sie die Fallback-Queue immer zuerst, wenn eine Ziel-Queue leer bleibt.
Zuweisung scheitert an Kapazität, Präsenz oder Skill
Landet der Case korrekt in der Queue, wird aber keinem Agenten zugewiesen, liegt es an der Zuweisungsstufe. Typisch: Der Skill-Matching-Algorithmus steht auf Exact Match, und obwohl Agenten die geforderten Skills besitzen, gibt es keine exakte Übereinstimmung. Auch fehlende Präsenz, ausgeschöpfte Kapazität oder fehlende Berechtigungen auf die Queue-Elemente stoppen die Zuweisung.
So diagnostizieren Sie das Problem
Statt zu raten, lassen Sie sich vom System zeigen, an welcher Stufe der Case hängt. Das schnellste Werkzeug sind die Routing-Diagnostics.
Routing-Diagnostics aktivieren und lesen
Aktivieren Sie die Diagnostics im Copilot Service Admin Center unter Routing. Für jeden verarbeiteten Case sehen Sie die vier Stufen Intake, Klassifizierung, Route-to-Queue und Zuweisung samt Status, Dauer und Fehlermeldungen. Eine rote Markierung zeigt die Stufe, an der die Verarbeitung abbricht. Wichtig zu wissen: Die Diagnosedaten stehen nach bis zu fünf Minuten bereit, die Aktivierung selbst kann bis zu 15 Minuten dauern. Microsoft hat das Diagnostics-Feature offiziell als veraltet gekennzeichnet, es funktioniert aber weiterhin und bleibt für die Fehlersuche der schnellste Einstieg. Für Konversationskanäle wandert die Analyse zunehmend in die Diagnose über Azure Application Insights.
Was die Stufen verraten
In der Intake-Stufe erkennen Sie, ob überhaupt eine Regel gematcht hat und welcher Workstream übernommen wurde. In der Route-to-Queue-Stufe zeigen die Diagnostics die geprüften Regeln, die final angewandte Regel und die Ziel-Queue. Sehen Sie hier die Fallback-Queue, wissen Sie, dass keine Ihrer Regeln zutraf. In der Zuweisungsstufe lesen Sie den Status-Grund pro Zuweisungsversuch ab, etwa ob kein Agent die Skill- oder Kapazitätskriterien erfüllt.
Die passenden Fixes
Aus der diagnostizierten Stufe ergibt sich der Fix meist direkt.
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Case erreicht kein Routing | Unified Routing nicht provisioniert oder Tabelle nicht für Queues aktiviert | Provisionierung prüfen, Case-Tabelle über Datensatzkanäle aktivieren, aktiven Workstream anlegen |
| Intake matcht nicht | Keine Intake-Regel oder falsche Reihenfolge | Intake-Regel dem Workstream zuordnen, Entscheidungsliste nach Spezifität ordnen |
| Case in Fallback-Queue | Keine Route-to-Queue-Regel trifft zu oder Klassifizierungsfehler | Regelbedingungen gegen echte Feldwerte prüfen, breite Fallback-Regel als letzte Regel ergänzen |
| Queue leer trotz Regel | Bedingung greift erst nach Statuswechsel | Zeitpunkt der Feldbefüllung prüfen, Bedingung auf beim Anlegen vorhandene Felder stützen |
| In Queue, keine Zuweisung | Exact Match ohne passenden Agenten, Kapazität oder Präsenz | Auf Closest Match wechseln, Skills, Kapazität und Präsenz der Agenten prüfen |
Praktisch bewährt hat sich eine bewusst breite Fallback-Regel am Ende des Route-to-Queue-Regelsatzes, die jeden nicht anderweitig zugeordneten Case in eine überwachte Standard-Queue leitet. So verschwindet nie ein Case unbemerkt in der Systemfallback-Queue. Ergänzend gehört zu jeder Konfiguration ein kurzer Testlauf mit einem echten Case und aktiven Diagnostics, bevor die Regeln in Produktion gehen.
Sauber aufgesetzt statt ständig repariert
Cases, die nicht in der Queue erscheinen, sind selten ein Fehler des Systems und fast immer eine Frage der Konfiguration. Wer die vier Stufen kennt, die Reihenfolge der Regeln pflegt und Bedingungen gegen den tatsächlichen Datenzustand bei der Erstellung prüft, baut eine vorhersehbare Routenführung. Wie eine durchdachte Routing-Architektur über alle Kanäle hinweg aussieht, zeigt unser Überblick zu Omnichannel-Routing-Strategien in Dynamics 365. Wenn Ihre Queues trotz sauberer Konfiguration leer bleiben, sprechen Sie uns an. Wir analysieren Ihre Workstreams und Regelsätze und bringen die Routenführung in einen wartbaren Zustand.
Häufig gestellte Fragen
Warum erscheint mein erstellter Case nicht in der Queue, obwohl Unified Routing konfiguriert ist?
Meist liegt es daran, dass eine der vier Routing-Stufen nicht durchläuft. Entweder ist Unified Routing nicht vollständig provisioniert, es existiert keine aktive Intake-Regel, die den Case einem Workstream zuordnet, oder keine Route-to-Queue-Regel trifft zu. In den letzten beiden Fällen landet der Case in der Fallback-Queue des Workstreams und nicht in der von Ihnen erwarteten Queue. Die Routing-Diagnostics zeigen genau, an welcher Stufe der Case stehenbleibt.
Was ist der Unterschied zwischen einer Intake-Regel und einer Route-to-Queue-Regel?
Eine Intake-Regel entscheidet, welcher Workstream einen eingehenden Datensatz übernimmt. Sie ist der erste Schritt beim Record Routing. Die Route-to-Queue-Regel läuft später innerhalb des Workstreams und bestimmt, in welche konkrete Queue der Case geleitet wird. Fehlt die Intake-Regel, startet Unified Routing für den Case gar nicht. Fehlt eine passende Route-to-Queue-Regel, landet er in der Fallback-Queue.
Was passiert, wenn keine Route-to-Queue-Regel auf einen Case zutrifft?
Wenn keine Regel definiert ist oder keine Regel die Bedingung erfüllt, leitet Unified Routing den Case in die Fallback-Queue des jeweiligen Workstreams. Dasselbe passiert bei einem Fehler während der Klassifizierung oder beim Ausführen einer Route-to-Queue-Regel. Der Case ist also nicht verloren, er steht nur in einer anderen Queue als erwartet.
Wird ein Case sofort bei der Erstellung geroutet?
Nicht zwingend. Ob ein Case bei der Erstellung oder erst nach einem Status- oder Feldwechsel geroutet wird, hängt von der Konfiguration der Datensatzkanäle und den Intake-Bedingungen ab. Prüft eine Intake-Bedingung ein Feld, das beim Anlegen noch leer ist, greift die Regel erst, wenn das Feld später gesetzt wird. Bis dahin bleibt die Queue leer.
Wie diagnostiziere ich, warum ein Case nicht zugewiesen wurde?
Aktivieren Sie die Routing-Diagnostics im Copilot Service Admin Center. Für jeden Case sehen Sie die vier Stufen Intake, Klassifizierung, Route-to-Queue und Zuweisung samt Status und Fehlermeldungen. Rote Markierungen zeigen die Stufe, an der die Verarbeitung abbricht. Die Diagnosedaten stehen nach bis zu fünf Minuten bereit. Das Feature ist offiziell veraltet, funktioniert aber weiterhin und ist das schnellste Diagnosewerkzeug.
Kann ein falsches Skill-Matching verhindern, dass ein Case zugewiesen wird?
Ja. Steht der Skill-Matching-Algorithmus auf Exact Match und kein Agent besitzt exakt die geforderten Skills, wird der Case zwar korrekt in die Queue geleitet, aber keinem Agenten zugewiesen. Er bleibt in der Queue liegen. Ein Wechsel auf Closest Match oder eine Korrektur der Skill-Anforderungen behebt das.
Sie haben Fragen zu Dynamics 365?
Wir haben die Antworten.
Vereinbaren Sie einfach ein unverbindliches Erstgespräch mit einem Dynamics-Experten.
Termin vereinbaren
