Microsoft Dynamics CRM 2011 | Zusammengeführte Kontakte filtern

Durch einen Blog-Beitrag erinnert an die Nachfrage aus einigen Anwender-Schulungen, möchte ich Euch heute mit einer Aufgabenstellung aus der Duplikatsbereinigung näher vertraut machen.

ErweiterteSuche_InaktiveKontakte

Wir alle kennen das Problem, da wurde versehentlich ein Kontakt erneut eingepflegt und trotz aktivierter Duplikatserkennung wurde der Kontakt gespeichert. Im Nachgang wird der Kontakt dann zusammengeführt, was für den Nutzer absolut okay ist, jedoch zu einigen Verwirrungen führen kann, wenn man den Prozess genauer durchleuchtet.

Denn beim Zusammenführen zweier aktiver Kontakte wird ein Kontakt deaktiviert und verweilt somit im System. Nun gibt es aber auch die Möglichkeit über die Oberfläche einen Kontakt anderweitig zu deaktivieren. Sagen wir einfach mal, jemand hat den Arbeitsplatz gewechselt und verweilt nicht mehr in einer Firma. Da wir die Nachfolgefirma noch nicht ausfindig gemacht haben, deaktivieren wir den Datensatz, um Ihn später zu reaktivieren und der neuen Firma zuzuweisen. Eine Erweiterte Suche auf inaktive Datensätze liefert mir nun aber, wie oben gezeigt zwei inaktive Datensätze aus denen ich nicht unterscheiden kann, welcher der deaktivierte und welcher der via Zusammenführungsprozess deaktivierte Kontakt ist.

Doch stimmt das wirklich?

InaktiverDatensatz

Es kommt darauf an. Denn schaut man sich die Datensätze im Detail an – öffnet also jeden Datensatz, so unterscheiden sich diese schon. Einmal sehen wir oberhalb des Abschnittes Allgemein keinen Eintrag.InaktiverDatensatz_aus_Zusammenführung

Einmal sehen wir eine gelbe Informationsleiste, der wir entnehmen, dass der Datensatz aus einer Zusammenführung entstammt und über den integrierten Link können wir sogar auf den verweilenden aktiven Datensatz “springen”.

Viele wollen solche Datensätze jedoch nach einer gewissen Zeit aus Ihren Systemen gelöscht haben. Also gilt es hier eine Ordnung in das Suchergebnis zu bekommen. Doch wie?

Identifikationsattribute_Zusammenführung

Dazu lohnt ein Blick “unter die Haube” des Systems. Die Designer haben hier zur Identifikation zwei Attribute Merged und MasterId integriert, die zusammengeführte Datensätze identifizieren. Schauen wir uns die beiden Attribute im Detail an.

Attribut_merged_Detailansicht

Dummerweise hat man hier die Option Durchsuchbar auf nein vorbelegt und kann diese Einstellung aus der Oberfläche heraus auch nicht ändern.

Attribut_master_id_DetailansichtUnd auch beim zweiten Attribut MasterId sieht es nicht besser aus. Auch dieses ist nicht durchsuchbar.

Was heißt dies für uns im Klartext?

ErweiterteSuche_KeinMasterID

In einer Erweiterten Suche sind diese Felder schlichtweg nicht auswählbar.

Im rot-markierten Bereich seht Ihr, dass ich weder MasterId aus den verknüpften Feldern, noch – glaubt es mir – Merged aus der Feldliste heraus auswählen kann.

D.h. ich kann diese Felder nicht zur Identifikation der Datensätze heranziehen, um jene deaktivierten Kontakte von solchen aus dem Zusammenführungsprozess erstellten zu unter-scheiden.

Was haben sich die Entwickler dabei wohl gedacht?

Meine Vermutung ist, dass Sie schlichtweg verhindern wollten, dass der Zusammen-führungsprozess nicht wie gewollt funktioniert, wenn Sie die Attribute zur Anpassung freigeben.

Doch kommen wir tatsächlich nicht an diese Attribute heran?

Was über die Erweiterte Suche nicht funktioniert, muss anderweitig nicht ausgeschlossen sein. Und so verhält es sich denn auch mit dem Feld MasterId.

Prozess_Überprüfungsbedingungen

Denn schaut man sich in den Prozessen bei einer hinzugefügten Überprüfungsbedingung die Eigen-schaften an, so stellt man fest, dass wir hier Master-ID (Kontakt) als Auswahl angeboten bekommen.

Und können wir dies für unsere Zwecke nutzen?

Ja, wenn wir davon ausgehen, dass jeder zusammen-geführte Kontakt eine Master-ID vererbt bekommt. Außerdem wissen wir, dass Nachname ein Pflichtfeld ist und deshalb dieser einen Inhalt haben sollte.

Und schon können wir diesen Umstand nutzen, um uns einen Prozess zu generieren, der uns hilft, die inaktiven Datensätze zu unterscheiden.

NeuesAttribut_Duplikatzusammengeführt

Dazu lege ich mir ein neues Attribut in den Kontakten an. Ein schlichtes Ja/Nein Optionen-Feld.

Man könnte auch die vorhandenen Felder nutzen und z.B. in das Beschreibungsfeld einen Eintrag setzen, doch so ein Attribut ist ja schnell erstellt und es sucht sich auch bequem danach (Erweiterte Suche).

Prozess_Duplikate_markieren

 

Nun erstellen wir uns einen neuen Prozess, der als Startargument Datensatzstatus wird geändert übergeben bekommt.

HINWEIS: Wenn Ihr bereits zusammen-geführte deaktivierte Datensätze unter-scheiden wollt, dann wählt Ihr auch den bedarfsabhängigen Prozess als Startargument.

Nun kommt unsere erarbeitete Logik. In einer Überprüfungsbedingung filtern wir nach Status = inaktiv und Master-ID – Nachname enthält Daten. Master-ID entnehmen wir dabei den verknüpften Feldern. Und da wir die ID nicht direkt ansprechen können, bedienen wir uns dem Hilfsfeld Nachname und prüfen schlichtweg auf Feldinhalt.

In dem Folgeschritt aktualisieren wir unser Attribut auf der Kontaktmaske.

KontaktEigenschaften_ZusätzlicheFelder

Da wir dies nicht auf die Form gebracht haben, um die Nutzer mit einem solchen Feld zu verwirren, finden wir dieses Feld unter Zusätzliche Felder gelistet in den Eigenschaften.

Dort setzen wir die Option auf Ja.

Wir schließen unseren Prozess noch mit einer Standard-Aktion ab, in dem wir den Prozess beenden, wenn die Überprüfungsbedingung nicht zutrifft und anschließend aktivieren wir unseren Prozess.

Fertig ist unser Identifikationsmerkmal.

Denn in einer Erweiterten Suche erhalten wir bei der Suche nach inaktiven Kontakten nunmehr die nachfolgende Ergebnisansicht, wenn wir unser Attribut als Spalte hinzufügen:

ErweiterteSuche_Identifikation_Duplikatbereinigung

Wir haben also die Möglichkeit zwischen deaktivierten und durch den Zusammenführungs-prozess deaktivierten Kontakten zu unterscheiden. Nun können wir die richtigen Datensätze löschen und andere deaktivierte Kontakte zur späteren Durchsicht/Weiterbearbeitung im System verweilen lassen, ohne den Überblick zu verlieren.

Für alle Entwickler: Ja, es gibt andere Ansätze, wie PlugIn-Programmierung oder FetchXML Auswertungen (Berichte), aber dies ist ein einfacher Prozess, kann von jedem integriert werden und auf asynchrone Ausführung muss keine Rücksicht genommen werden, weil man das Ergebnis nicht unmittelbar sofort benötigt.

Ich hoffe, Euch damit aufgezeigt zu haben, dass es manchmal wertvoll ist, einen Blick in das SDK zu nehmen, um Zusammenhänge ausfindig zu machen, auch wenn man nicht programmieren möchte.

 

Technorati Tags:

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