Microsoft Dynamics CRM 2011 | Notifications using Workflows

NOTI_E-Mail_Details

Jüngst wurde ich durch einen Artikel im Forum wieder auf ein Szenario aufmerksam gemacht, dass in der Praxis sehr häufig nachgefragt wird.

Eine E-Mail Benachrichtigung für Verkaufschancen, wenn das geschätzte Abschlussdatum erreicht bzw. in der Vergangenheit liegt.

Eine durchaus geläufige Lösung liegt in der Nutzung der Warten bis-Kondition für Workflows (Prozesse). Aber war da nicht was in Sachen Performance und Asynchroner Verarbeitungstabelle?

Exakt, die Warten bis-Kondition in Prozessen sollte, wann immer es geht, vermieden werden. Insbesondere ist sie problematisch, wenn nicht einer, sondern N Workflows im wartenden Zustand im System verweilen.

Doch muss es in diesem Fall denn gleich eine Plug-In Programmierung sein?

Heute möchte ich Euch die wahre Power, des Codeplex Projektes CRM 2011 Distribute Workflow Activity zeigen.

Denn mit einfachsten Bordmitteln, können wir o.g. Szenario lösen, ohne 500+ wartende Workflows im System für Verkaufschancen vorhalten zu müssen.

NOTI_SolutionPackage

Das gesamte Lösungspaket besteht aus

1 – Benutzerdefinieren Entität inkl. entsprechender Webressourcen
1 – Verkaufschancen-Entität

der Distribute Workflow Activity Lösung, sowie 2 Prozessen.

Zunächst installieren wir in unserem System die CRM 2011 Distribute Workflow Activity Lösung.

NOTI_Opptys

Und natürlich benötigen wir in unserem System auch ein paar Verkaufschancen mit entsprechenden Datums-angaben im Feld “Gesch. Abschlussdatum”.

NOTI_EntityJetzt erstellen wir uns eine neue Lösung oder passen unser System direkt an und erzeugen im ersten Schritt eine neue Benutzerdefinierte Entität “Benachrichtigungen”.

Neben dem Namen, richten wir ein weiteres Feld vom Typ Datum/Zeit ein – unser nächstes Ausführungsdatum. Im Anschluss fügen wir das Feld unserem Formular hinzu und veröffentlichen die Anpassungen. Jetzt können wir die Entität noch schön machen und mit entsprechenden Webressourcen (Symbolen) ausstatten.

NOTI_Oppty_Entity

Im nächsten Schritt fügen wir der Lösung die Verkaufs-chancen-Entität hinzu und passen auch hier das Formular an. Wir schaffen uns zunächst ein Suchfeld (Lookup) auf unsere neue Entität Benachrichtigungen. Und das Feld platzieren wir anschließend auf dem Formular.

Erneut veröffentlichen wir alle Anpassungen und widmen uns nunmehr der eigentlichen Logik – den steuernden Prozessen (Workflows).

NOTI_Reminder_Process

Unser 1. Prozess läuft auf der Entität Verkaufschance als “untergeordneter Prozess”. Dieser enthält die Logik der Erstellung einer E-Mail, sofern das Gesch. Abschlussdatum am oder nach dem aktuellen Datum.

Wie kommt Ihr an das aktuelle Datum? Ihr nutzt einfach die Ausführungszeit des Prozesses und habt damit immer das aktuelle Datum.

Weitere Tipps:

Ihr solltet den Workflow erfolgreich beenden, wenn die Bedingung nicht zutrifft.

Ihr solltet in den Optionen den Haken setzen, die erfolgreich ausgeführten Workflows gleich zu löschen, so dass Eure Systemaufträge entsprechend bereinigt werden.

 

Nachdem Ihr diesen Prozess gespeichert habt, könnt Ihr Ihn auch gleich aktivieren.

NOTI_Maintenance_ProcessWir erstellen nunmehr unseren Maintenance Job – ein weiterer Prozess der auf unserer neuen Entität Benachrichtigungen läuft und bei der Erstellung des Datensatzes, sowie als untergeordneter Prozess gestartet wird/werden kann.

Zu Demonstrationszwecken, habe ich den Start auch bedarfsabhängig eingerichtet.

In unserer Logik integrieren wir nunmehr ein Timeout, bis unsere Nächste Ausführungszeit erreicht ist.

In den weiteren Schritten folgen:

a) Der Start des untergeordneten Prozesses unserer Benachrichtigung. Hierzu benötigen wir den neuen Schritt, der uns nach der Installation der Distribute Workflow Activity zur Verfügung steht. In den Eigenschaften müssen wir hier den Prozess auswählen und den Relationsnamen angeben. Diesen findet Ihr in der Beziehung zwischen Verkaufschancen und Benachrichtigungen.

b) Ein Update des Feldes Nächste Ausführungszeit. In meinem Beispiel setze ich die Zeit einfach nur 5 Minuten weiter. Ihr könntet den nächsten Lauf aber auch auf den nächsten Tag / um X Uhr legen

c) Ein Aufruf des gleichen Prozesses, damit dieser erneut startet.

Nachdem Ihr auch diesen Prozess gespeichert und veröffentlicht habt, ist die Logik komplett.

Und jetzt zeige ich Euch die Anpassungen in der Praxis.

NOTI_MaintenanceJobIhr richtet einen neuen Benachrichtigungs-Job ein, vergebt einen passenden Namen und bestimmt die nächste Ausführungszeit.

Im Anschluss daran, aktualisiert Ihr Eure Verkaufschancen und setzt im Suchfeld der Benachrichtigungen diesen neuen Job (mit Jobnamen) ein. Dies kann z.B. ebenfalls per Prozess passieren, wenn Ihr mehrere Verkaufschancen aktualisieren müsst.

NOTI_Processes

Bei einem Blick in die Prozesse zu Eurer neuen Benachrichtigung stellt Ihr fest, dass der entsprechende Maintenance-Prozess bereits begonnen hat und eine weitere Instanz wartet.

In meinem Fall auf die Tatsache, dass die nächste Ausführungszeit 5 Min. später als die erste Zeit liegt, die ich gesetzt habe.

NOTI_Updated_NextRunWenn Ihr einen Blick auf den Datensatz nehmt, stellt Ihr fest, dass die Uhrzeit um 5 Minuten aktualisiert wurde, Eure Logik also funktioniert.

Und wenn Ihr einen Blick auf die Aktivitäten werft und hier die E-Mail Aktivität auswählt, dann seht Ihr, dass für die Verkaufschancen, bei denen das Gesch. Abschlussdatum am oder nach dem aktuellem Datum liegt, mit einer entsprechenden E-Mail Benachrichtigung versehen worden sind.

NOTI_E-Mails_for_Opptys

 

In meinem Beispiel ist für die 3. Verkaufschance, die ich auf den 3. September gelegt hatte, keine Benachrichtigung per E-Mail erzeugt worden.

Weitere Tipps:

Arbeitet doch z.B. auch mit der Eskalationstechnik. D.h. verschiebt diese Verkaufschancen in eine spezielle Warteschlange, um zu signalisieren, dass sich hierum gekümmert werden sollte.

 

Was bietet uns diese Technik für Vor- und Nachteile?

Vorteile

Nachteile

– Nur 1 Workflow pro Benachrichtigungs-maintenance Job bleibt im Status “wartend – Installation der DWA-Lösung
– No-Code Benachrichtigungslogik – Auf jeder VKC muss ein Link zum Benachrichtigungs-Job angegeben sein.
– Überwachung der Ausführung über Systemaufträge  
– Die Systemaufträge bleiben “clean – vorerst keine Unterstützung von Microsoft Dynamics CRM Online
– Flexibel auch auf andere Entitäten anwendbar  

Natürlich könnte man diese Lösung auch noch an diversen Stellen “tunen”. Ich hoffe aber, dass Euch dieses Praxis Beispiel gezeigt hat, dass nicht immer Plug-Ins erforderlich sind, um gewisse Aufgaben im System zu erledigen.

Und betrachtet man die Relation zwischen einem wartenden Maintenance-Job auf N Verkaufschancen zu N wartenden Benachrichtigungsjobs direkt an jeder Verkaufschance, so dürfte klar sein, welchen Performance-Gewinn diese Technik hat.

Viel Spass in der Umsetzung.

 

Technorati Tags:

Ein Gedanke zu “Microsoft Dynamics CRM 2011 | Notifications using Workflows

  1. Hi,

    vielen Dank, super Tipp!!

    Du schreibst „Ihr könntet den nächsten Lauf aber auch auf den nächsten Tag / um X Uhr legen“ –> daran scheitere ich.

    – Wenn ich im Formular „1 Tag nach ‚Erstellt am'“ auswähle, kann ich keine fixe Uhrzeit eingeben.
    – Wenn ich einen Defaultwert setze, kann ich kein variables Datum eingeben, sondern nur ein bestimmtes auswählen

    Wäre super dankbar für einen Tipp.

    Viele Grüße,
    Andreas

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