A Grundsätzliches
=================
Es gibt mehrere Benachrichtigungstypen, die von Lotus Workflow zur Verfügung gestellt werden und zwar:
1. "Neuer Job liegt an"
2. "Neuer Job liegt zu lange unbearbeitet rum"
3. "Bearbeitung des Jobs dauert zu lange"
4. "Automatische Mail"
Für jeden Mailtyp gibt es ein von Lotus Workflow festgelegtes Standardverhalten und einen Standard-Mailinhalt. Anpassungen lassen sich wie auch in anderen Fällen in der ScriptLibrary "Application Events" durchführen.
In dieser ScriptLibrary kann man einerseits die Parameter der Funktionen benutzen und deren Inhalte erweitern (z.B. einen weiteren Adressaten bei "Recipients" hinzufügen). Dabei bleibt aber die Struktur und der Inhalt der Mail so, wie Lotus Workflow es vorgibt.
Andererseits kann man die Mails von Lotus Workflow über den Parameter "continue" stoppen und eine eigene Mail erstellen und verschicken. "continue = false" ist wichtig, da sonst zwei Mails verschickt werden: die Eigene und die vom Workflow.
Da man öfter in die Verlegenheit kommt eigene Mails bei Lotus Workflow zu verschicken lohnt es sich eine "SendMail"-Funktion zu erstellen, die die Mail erzeugt und verschickt. Diese benutzt man dann an den verschiedenen Stellen. Den Fehler "unable to send mail to" beim Mail verschicken sollte man abfangen (taucht z.B. auf, wenn der Adressat nicht im Adressbuch vorhanden ist).
Grundsätzlich sind zwei Agenten von Lotus Workflow zuständig für das Versenden der Mails: der Workflow-Backgrounder und der Timemanagement-Backgrounder. Das bedeutet natürlich, das deren Einstellungen beeinflussen, wann und ob eine Mail verschickt wird. D.h., wenn man möchte, das eine Benachrichtigung alle 15 min. versendet wird, der Agent aber nur jede Stunde läuft, ist das nicht so gut :-)
Allen Anwendern muss der Grundablauf im Workflow klar sein: <Aktivität wurde beendet> - <Job wird weitergeleitet> - <Eventuell Benachrichtigung> - <Claim&Edit> - <Eventuelles Zwischenspeichern> - <Save&Complete> - <Erneute Weiterleitung zur nächsten Aktivität>. Sollten den Anwendern diese (und ein paar andere) Grundlagen fehlen werden unweigerlich folgende Situationen eintreten:
- Support-Anfragen bezüglich der Bedienung des Workflows
- Jobs die weitergeleitet wurden, obwohl der User es nicht wollte
- Jobs die zwischengespeichert rumliegen und nicht weitergeleitet werden
An Schulungen bzw. Einführungen wird ja gern gespart. Hier kann dies zu erheblicher(!) Mehrarbeit bei der Verwaltung der Workflows führen (sagt nicht ich hätte euch nicht gewarnt).
B Die Benachrichtigungs-Typen im einzelnen:
=============================================
1. "Neuer Job liegt an"
-------------------------------------
Ein Workflow-Job wird zur nächsten Aktivität weitergeleitet und für diese Aktivität ist in deren Basis-Eigenschaften (im Architect) angegeben,das eine Benachrichtigung verschickt werden soll. Beim nächsten Lauf des Backgrounder-Agenten wird eine einmalige Benachrichtigung verschickt, falls der Job immer noch ungeclaimed ist.
Vorsicht: das bedeutet, das es Situationen gibt, in denen auf diese Weise keine Benachrichtigung verschickt wird (Benutzer claimed vor nächstem Lauf des Workflow-Backgrounder). Dies kann bei unbedarften Anwendern zur Verwirrung führen - also den meisten.
Die Funktion, in der wir die Benachrichtigung anpassen können heisst "QueryInboxMailNotification".
Die Leute, die diese Information interessieren sollte (potentielle Activity Owner) stehen im MainDocument des Jobs im Feld "ExpandedParticipantAuthorsOS"
2. "Neuer Job liegt zu lange unbearbeitet rum"
-----------------------------------------------
Ein Job liegt ungeclaimed seit einer längeren Zeit herum, keiner der potentiellen Activity Owner kümmert sich darum. Der TimeManagement-Backgrounder verschickt diese Mail, gesteuert durch die Timing-Parameter der Aktivität im Architect.
Die Funktion, in der wir diese Benachrichtigung anpassen können heisst "QueryInboxOverDueMail".
Bitte daran denken: die Leute, die diese Information interessieren sollte (potentielle ActivityOwner) stehen im MainDocument des Jobs im Feld "ExpandedParticipantAuthorsOS"
3. "Bearbeitung des Jobs dauert zu lange"
-----------------------------------------------------
Ein Job wurde geclaimed, der Benutzer hat ihn aber zu lange nicht weitergeleitet. Dies wird ebenfalls vom TimeManagement-Backgrounder gesteuert mit Hilfe der Timing-Parameter.
Die Funktion, in der wir diese Benachrichtigung anpassen können heisst "QueryActivityOverDueMail".
Bitte daran denken: die Person die diese Information interessieren sollte (die Person, die den Job geclaimed hat) steht im MainDocument des Jobs im Feld "ActivityOwnerOS"
4. "Automatische Mail"
---------------------------------------
Benutzen wir in unserer Prozessdefinition im Architect eine automatische Aktivität, gibt es dort die Möglichkeit eine Mail verschicken zu lassen. Man kann den Titel, Inhalt und Adressaten im Architect angeben. Diese Angaben stehen dann in LotusScript wieder zur Verfügung.
Da eine Änderung der Mail im Architect das Einspielen eines neuen Prozesses bedeutet, würde ich hier nur Dummy-Einträge vornehmen und die Verarbeitung in der ScriptLibrary durchführen.
Die Funktion, in der wir diese Benachrichtigung anpassen können heisst "QueryAutomatedActivityMail".
C Format einer eigenen Mail
===========================
Hier sollte man daran denken, das die Benutzer auf einen Blick im Titel der Mail erkennen wollen das es eine Workflow E-Mail ist (für die Benutzer bedeutet dies meistens Arbeit) und worum es geht.
Dies erreicht man dadurch, das man die wichtigsten Feldwerte mit in den Titel übernimmt. Welche nehme ich? Ein Ansatz wäre sich zu überlegen welche Werte ein Dokument eindeutig identifizieren (also der eindeutige Schlüssel). Diese sind häufig auch gut, um sie in die Mail aufzunehmen.
Der Inhalt der Mail ist Geschmackssache. Beispiele: Wiederholung der wichtigen Feldwerte, Kurzbeschreibung, was vom Benuzzer jetzt gefordert ist, Hinweis keine Antwort auf die Mail zu schreiben. Eine Idee um Mails eindeutig zu kennzeichnen ist das Icon, das in der Inbox angezeigt wird. Dieses wird in einer Mail (Maske "Memo") über das Feld "_ViewIcon" manipuliert.
In die Mail gehört ausserdem ein Link zum MainDocument des Workflow-Jobs, damit man bequem direkt das Dokument öffnen kann. Benutzer tendieren dazu die Workflow Datenbank ausschliesslich über diese Links zu benutzen (schade um die schönen Ansichten, die man im Schweisse seines Angesichts erstellt hat). Ein zusätzlicher Link in die Ansicht "My Activites" könnt hier eine therapeutischen Wirkung haben.
D Andere Benachrichtigungen
===========================
Hier noch ein paar Ideen für Benachrichtigungen, die man zusätzlich in Workflows einbauen kann.
1. Eskalation
--------------
Es kann sinnvoll sein, eine Benachrichtigung zu eskalieren, wenn Sie z.B. schon mehrere Male an die eigentlich Verantwortlichen gegangen ist, aber nichts passiert ist. Dies kann man z.B. in den oben genannten Funktionen programmieren:
- Zähler im Dokument, der die Anzahl der versendeten Mails zählt.
- Im Durchlauf x wird ein neuer Adressat ebenfalls benachrichtigt
- Eskalation in Mail besonders hervorheben
2. Benachrichtigung ausserhalb der Reihe
----------------------------------------
Ein Benutzer (ActivityOwner) meint der Job interessiert noch weitere Personen, die sonst nichts mit dem Workflow zu tun haben. Hier bitte daran denken (und es bei der Programmierung berücksichtigen), das die Personen Leserecht auf den Job haben müssen. Je nach Einstellung des Prozesses ist die automatische Berechtigung zum Lesen/Bearbeiten sehr restriktiv. Das bedeutet:
- Auswahl einer Person zur Benachrichtigung vom Benutzer aus Adressbuch oder noch besser Organisations-Datenbank
- Speicherung des Namens/der Namen in Job. Anzeigen der benachrichtigten Personen nicht vergessen.
- Für Leserecht der ausgewählten Personen sorgen (z.B. über zusätzliches Lesefeld - hängt aber von den schon eingesetzten Zugriffsbeschränkungen ab)
Hierbei benutzt man z.B. die Funktion "QueryActivityCompleted" der ScriptLibrary: Versenden der Mail beim Übergang von einer Aktivität zur anderen.
3. Aktueller Status
-------------------
Benachrichtigung von Personen, das der Job einen bestimmten Status erreicht hat. Häufig soll zum Beispiel der Initiator immer mal wieder Bescheid bekommen.
Dafür gibt es natürlich die unterschiedlichsten Möglichkeiten, aber "QueryActivityCompleted" ist auch hier keine schlechte Wahl.