Microsoft Dynamics CRM 2011 | Warteschlangenchaos nach Upgrade

Wie fast alles im Leben beginnt etwas Gutes mit einem Plan – Wer auf diesen verzichtet, muss mit den Konsequenzen leben, richtig?

Unübersichtlich_AlleWarteschlangenWer sich dieser Tage mit einem Upgrade von 4.0 auf 2011 beschäftigt, der sollte sich – neben vielen anderen Themen – auch das der Nutzung von Warteschlangen in seine Upgrade-Checkliste notieren. Denn mit dem Upgrade kann ein ziemlich verwirrendes Chaos entstehen.

Im schlimmsten Fall sieht es dann für den Nutzer so, wie auf dem linken Bild zu sehen aus, wenn er ein Element einer Warteschlange zuweisen möchte.

Warteschlangen_NurEigeneElemente

Zwar kann man mit einer neuen Option in den Lookups – siehe rote Markierung – die Anzeige einschränken und es scheint schon übersichtlicher zu werden. Doch will man im Zweifel ja das Element nicht einer in seinem Besitz befindlichen Warteschlange zuweisen, sondern einer anderen im System hinterlegten.

Doch wie kommt es eigentlich zu diesem Anzeige-Chaos?

Blickt man in die Historie zurück, gab es neben den öffentlichen Warteschlangen schon immer zwei individuelle Warteschlangen für jeden Nutzer.

Jene mit den “In Bearbeitung”-befindlichen Elementen und jene mit den “Zugewiesen”

Und was passiert mit den Warteschlangen beim Update?

Da ich mich nicht wiederholen möchte, findet Ihr hier die Beschreibung für den Upgrade-Prozess. Im Klartext gibt es also nach dem Upgrade auf CRM 2011 für jeden Nutzer zwei Warteschlangen:

<Nachname, Vorname> und

DOMAIN\User´s name WIP queue

*WIP = Working In Progress

Und wer sich vorher kein Konzept überlegt hat, der handelt nach den Anweisungen im Artikel.

WarteschlangeKannNichtGelöschtWerdenDort heißt es unter anderem als Nachgang zum Upgrade-Prozess kann man die DOMAIN\User´s name WIP Warteschlangen löschen.

Wer dies direkt probiert, wird mit jenem Fenster ernüchtert. Natürlich kann man keine Warteschlangen löschen, denen noch Elemente zugewiesen sind.

ElementeVorZuweisung

Schauen wir uns exemplarisch eine solche Warteschlange an, so sehen wir, dass die Warteschlange noch Elemente enthält, die zunächst entfernt werden müssten, um die Warteschlange löschen zu können – doch HALT !

Handelt es sich nicht um die WIP (Working in Progress) Elemente? Alle zu löschen/ zu entfernen wäre nur angebracht, wenn wir auch wirklich wüssten, dass eine Bearbeitung stattgefunden hat.

DefaultAnsichtWarteschlangenFirstLoginFürBearbeitungVerfügbareElementeNachZuweisung

Und auch im neuen Warteschlangenkonzept, gibt es eine Ordnung:

Es gibt Alle Elemente, Elemente in Bearbeitung und Für Bearbeitung verfügbare Elemente. Im Gegensatz zu der 4.0 Darstellung (untereinander), sind es hier jedoch quasi gefilterte Listen auf eine Warteschlange.

Kommen wir also zurück auf den Artikel, in dem es heißt, wir mögen die Elemente zuvor zuweisen.

Warteschlangen_Buttons

In der GUI habe ich dafür eine Schaltfläche “Routing”, die mir ermöglicht ausgewählte Elemente “zu verschieben”.

RoutingAnBenutzer_NoGo

Die nächste Verwirrung stellt sich ein. Denn ist man der Meinung es würde ausreichen die Elemente erneut dem jeweiligen Nutzer zuzuweisen (damit Sie in dessen persönlicher Warteschlange landen), so stellt man fest, dass einem der Abschluss des Dialoges mit OK leider nicht gestattet ist. Schon könnten Fragen auftauchen wie:

Darf nur ich das nicht?

Ist es ein fehlendes Sicherheitsrecht?

Sucht nicht lange in den Rollen – Dieser Schritt ist für Elemente aus der DOMAIN\User´s name WIP queue designbedingt nicht gewünscht.

ElementeNurInWarteschlangeWeiterleiten

Wählen wir stattdessen doch einfach im ersten Lookup-Fenster die persönliche Warteschlange des Nutzers aus <Nachname, Vorname>

Zur Belohnung erhalten wir die OK Schaltfläche schwarz hinterlegt und können den Dialog abschließen.

Schon werden die ausgewählten Elementen in die Warteschlange verschoben.

Doch wohin genau? In Elemente in Bearbeitung oder in Für Bearbeitung verfügbare Elemente?

FürBearbeitungVerfügbareElementeNachZuweisung

Eigentlich wollte man Sie ja direkt zuordnen zu Elemente in Bearbeitung – denn Sie waren vorher ja auch in Bearbeitung.

Landen tun Sie jedoch in dem “Container” Für Bearbeitung verfügbare Elemente.

Und noch ein Problem tut sich auf: Das Bearbeitungsdatum ist natürlich auf das aktuelle Datum “umgebucht”, da Sie ja gerade erst von mir manuell der Warteschlange zugewiesen wurden.

Und wem es nicht aufgefallen ist, ich kann nur maximal 250 Elemente zeitgleich markieren und in die Warteschlange einstellen.

Es bleiben also offene Punkte:

  1. Habe ich sehr viele Elemente in der ursprünglichen Warteschlange, so kann es eine Weile dauern, diese in die persönliche (verbleibende) Warteschlange neu zuzuweisen
  2. Die Elemente liegen lediglich in Für Bearbeitung verfügbare Elemente – Der Nutzer oder der Administrator müssten also ein weiteres Mal Hand anlegen, um die Elemente in den “Container” Elemente in Bearbeitung zu verschieben
  3. Das ursprüngliche Datum der Einstellung ist verloren gegangen. Anhand dessen kann der Nutzer aber oftmals die Priorität einstufen, um welches Element sich als nächstes gekümmert werden sollte
  4. Und was ist eigentlich mit dem Löschen?

LöschenWarteschlangeDie gute Nachricht vorweg: Nachdem die Warteschlange DOMAIN\User´s name WIP queue geleert wurde, lässt Sie sich auch löschen !

Doch was ist mit den o.g. Punkten?

Gibt es hierfür eine Lösung aus der GUI heraus?

NeuerWarteschlangeZuweisen_BenutzerZuweisen

 

 

 

Zurück also zum Dialog. Was passiert denn, wenn ich im 1. Lookup die persönliche Warteschlange auswähle und im 2. Lookup den Nutzer erneut auswähle?

DefaultAnsichtWarteschlangenFirstLogin

 

 

Ich bin in einer Testmigration – also doch schnell kontrolliert. Und siehe da: Die Elemente landen jetzt in dem Container Elemente in Bearbeitung.

Über die grafische Oberfläche ist es also tatsächlich möglich, die Elemente in den korrekten “Container” einstellen zu können.

Allerdings können auch hier – je nach Einstellung des Nutzers – viele Schritte notwendig sein, da maximal 250 Elemente zeitgleich markiert und verschoben werden können. Und leider ändert sich besagtes Datum der Einstellung in die Warteschlange und das ursprüngliche Datum wird nicht erhalten.

Mein persönliches Fazit ist daher – wenn auch unsupported der Eingriff auf SQL-Ebene und hier Korrektur der QueueId, um das ursprüngliche Datum zu erhalten.

Aber auch noch eine Erkenntnis: Es ist vor der Upgrade auf 4.0 ratsam den Nutzern die Aufgabe zu erteilen in seinen beiden persönlichen Warteschlangen kräftig aufzuräumen und nur die aktuellen Elemente dort zu belassen, die dann migriert werden. Denn Ihr kennt ja den Umstand, dass die E-Mail Elemente sich aus den Warteschlangen leider nicht automatisch entfernen. So sammeln sich hier Massen an Elemente, für die es im Nachgang kaum eine Entscheidung zu treffen gilt: Behalten / Entfernen / Neu zuweisen / In welchen Container?

Eine Fragestellung bleibt jedoch noch offen? Was passiert eigentlich, wenn auch die persönliche Warteschlange gelöscht wird. Doch dieser Artikel ist schon sehr lang geraten und daher folgt ein zweiter Artikel gesondert zu diesem Thema.

 

Technorati Tags:

2 Gedanken zu “Microsoft Dynamics CRM 2011 | Warteschlangenchaos nach Upgrade

  1. Pingback: Microsoft Dynamics CRM | Tipps zur Grundkonfiguration (1) « Microsoft Dynamics CRM & Co
  2. Pingback: Microsoft Dynamics CRM 2011 | Warteschlangen nach Upgrade löschen? « Microsoft Dynamics CRM & Co

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s