Case Routing Konflikte vermeiden: Wenn Workflow, Routing Rule und ARC sich gegenseitig überschreiben

In Dynamics 365 Customer Service können vier verschiedene Mechanismen einen Case zuweisen: klassische Workflows und Cloud Flows, Basic Routing Rules, Unified Routing und die Regeln der Automatic Record Creation (ARC). Laufen mehrere davon aktiv nebeneinander, schreiben sie fast gleichzeitig auf dieselben Felder, also owner und queue. Das Ergebnis sind Doppelzuweisungen, stille Überschreibungen und Cases, die niemand verlässlich verantwortet. Dieser Beitrag erklärt, warum diese Mechanismen kollidieren und wie Sie sauber auf einen führenden Weg standardisieren.

Die vier Wege, auf denen ein Case zugewiesen wird

Bevor man Konflikte auflöst, muss man die Beteiligten kennen. Jeder dieser Mechanismen kann einen Case anlegen, ihm einen Besitzer geben oder ihn in eine Queue schieben. Das Problem beginnt, sobald zwei davon dieselbe Aufgabe übernehmen.

Klassische Workflows und Cloud Flows

Klassische Hintergrund-Workflows und moderne Cloud Flows in Power Automate lassen sich so bauen, dass sie beim Anlegen oder Ändern eines Case den owner setzen oder den Case in eine Queue legen. In vielen gewachsenen Systemen ist das der historisch erste Automatismus, oft Jahre vor der Einführung eines echten Routing Modells eingerichtet. Genau diese alten Prozesse werden später leicht übersehen.

Basic Routing Rules

Basic Routing Rules sind das ältere, regelbasierte Routing. Sie werten Bedingungen auf dem Case aus und weisen ihn einer Queue oder einer Person zu. Ihre Grenze ist klar: Basic Routing kann nur Cases routen. Für andere Datensatztypen oder Kanäle war es nie gedacht.

Unified Routing

Unified Routing ist das moderne, kanalübergreifende Zuweisungsmodell von Dynamics 365. Es arbeitet über Workstreams und trennt zwei Phasen: Klassifizierung und Zuweisung. In der Klassifizierung reichern Regeln und Modelle das Arbeitselement mit Kontext an, in der Zuweisung wird nach Priorität, Fähigkeiten und aktueller Auslastung an die am besten geeignete Serviceperson verteilt. Es deckt Cases, Datensätze, Chat und E-Mail einheitlich ab. Microsoft beschreibt es als das empfohlene, skalierbare Routing für Customer Service.

Automatic Record Creation Regeln

ARC Regeln erzeugen automatisch Cases aus eingehenden Aktivitäten, etwa aus E-Mails in einer Warteschlange oder aus sozialen Nachrichten. Der Zweck ist die Fallanlage. Problematisch wird es, wenn dieselbe ARC Regel oder ein daran gekoppelter Flow bereits owner oder queue setzt, obwohl anschließend das Routing entscheiden soll.

Warum die Zuweisung kollidiert

Alle vier Mechanismen können auf dieselben zwei Felder schreiben: ownerid und die Queue-Zugehörigkeit. Solange nur einer aktiv ist, ist das unkritisch. Sobald zwei oder mehr auf dasselbe Ereignis reagieren, entsteht ein Wettlauf.

Der typische Ablauf sieht so aus: Eine ARC Regel legt den Case an und setzt einen vorläufigen owner. Fast zeitgleich prüft eine Basic Routing Rule ihre Bedingungen und verschiebt den Case in eine Queue. Ist zusätzlich Unified Routing über einen Workstream aktiv, weist es den Case einer Serviceperson nach Auslastung zu. Am Ende gewinnt der zuletzt geschriebene Wert, und welcher das ist, hängt von Timing und Ausführungsreihenfolge ab, nicht von Ihrer fachlichen Absicht.

Drei Effekte treten dabei besonders häufig auf:

• Doppelzuweisung: Ein Case landet gleichzeitig in einer Queue und bei einer Einzelperson, sodass unklar ist, wer ihn bearbeitet.
• Stille Überschreibung: Eine korrekte Zuweisung wird Sekunden später von einem zweiten Prozess überschrieben, ohne Fehlermeldung. Die Zuweisung wirkt zufällig.
• Race Conditions: Synchrone und asynchrone Prozesse laufen nicht in stabiler Reihenfolge. Derselbe Fall wird mal so, mal anders zugewiesen, was die Diagnose erschwert.

Der Grund, warum diese Probleme so hartnäckig sind: Sie treten selten sofort auf. In der Testphase mit wenigen Cases greift meist zufällig der gewünschte Prozess zuletzt und alles wirkt korrekt. Erst unter Last, mit parallelen Zuweisungen und wechselnder Auslastung, kippt die Reihenfolge und die Konflikte werden sichtbar. Bis dahin ist die Ursache in mehreren Prozessen verstreut und schwer nachzuvollziehen.

Erschwerend kommt ein Zusammenspiel hinzu, das Microsoft ausdrücklich dokumentiert: Nach der Aktivierung von Unified Routing routen aktive Basic Routing Rules erst wieder, wenn Intake Rules konfiguriert sind. Wer beide Modelle halb konfiguriert nebeneinander betreibt, bekommt Cases, die scheinbar gar nicht mehr geroutet werden.

Die Mechanismen im direkten Vergleich

Die folgende Tabelle zeigt, wofür jeder Mechanismus gedacht ist und wo er kollidiert, wenn er die Zuweisung übernimmt.

Auf einen führenden Mechanismus standardisieren

Die Lösung ist kein cleverer Trick, mit dem sich mehrere Routing Modelle vertragen. Die Lösung ist eine Entscheidung: Genau ein Mechanismus weist zu, alle anderen halten sich zurück. Für neue und wachsende Serviceorganisationen ist das Unified Routing.

Konkret bedeutet das vier Schritte:

• Unified Routing als führend setzen. Definieren Sie Workstreams, Klassifizierung und Zuweisungsregeln so, dass sie owner und queue als einzige Instanz vergeben. Wenn Sie mehrere Kanäle bedienen, ist das ohnehin der einzige Weg, der Chat, E-Mail und Cases konsistent behandelt. Wie sich das in eine breitere Servicelandschaft einfügt, zeigt unser Überblick zu Omnichannel-Routing-Strategien in Dynamics 365.
• Alte Regeln deaktivieren. Schalten Sie Basic Routing Rules ab, die dieselben Cases betreffen, und deaktivieren Sie klassische Workflows und Cloud Flows, die owner oder queue setzen. Erst wenn nur noch ein Mechanismus schreibt, verschwinden Doppelzuweisung und stille Überschreibung.
• Fallanlage und Routing trennen. Lassen Sie ARC Regeln den Case anlegen und mit Kontext füllen, aber keine Zuweisung vornehmen. Die Zuweisung entscheidet danach ausschließlich das Routing. Diese saubere Trennung von Verantwortlichkeiten verhindert, dass zwei Prozesse denselben Job machen.
• Begleitlogik behalten, Zuweisung herausnehmen. Workflows und Flows dürfen weiterhin benachrichtigen, Statusfelder pflegen oder Daten anreichern. Nur die Felder owner und queue gehören allein dem führenden Routing.

Wenn nach dieser Bereinigung Cases scheinbar gar nicht mehr ankommen, liegt es fast immer an fehlenden Intake Rules oder an einer Queue, aus der niemand liest. Diesen Fall behandeln wir ausführlich im Beitrag dazu, warum Cases nicht in der Queue erscheinen.

Der Weg zur konfliktfreien Zuweisung

Bevor Sie umstellen, verschaffen Sie sich einen vollständigen Überblick. Listen Sie alle aktiven Prozesse auf der Case-Tabelle auf, prüfen Sie im Audit Log, welche Prozesse owner und queue in den letzten Wochen geschrieben haben, und markieren Sie jeden Mechanismus, der zuweist. Erfahrungsgemäß findet sich dabei mindestens ein vergessener Workflow aus früheren Jahren.

Testen Sie die neue Konfiguration in einer Sandbox, bevor sie in die Produktion geht. Microsoft empfiehlt genau das, weil das Aktivieren von Unified Routing über einen Solution-Import auch die Laufzeit beeinflussen kann. Erst wenn die Zuweisung in der Testumgebung stabil und vorhersehbar läuft, folgt der Produktivschritt. Ein durchdachtes Routing ist am Ende ein wesentlicher Baustein von Service Excellence in der digitalen Transformation.

Wenn Sie unsicher sind, welche Ihrer bestehenden Prozesse Cases zuweisen und wie Sie ohne Ausfall auf Unified Routing standardisieren, sprechen Sie uns an. Wir analysieren Ihre aktiven Routing Mechanismen und bauen ein Modell, in dem genau ein Weg entscheidet.