/
Workflows

Workflows

Owned by Testify
Last updated: May 14, 2024

Inhaltsverzeichnis

Unter “Administration” im Bereich "Workflows" kann die Testify-Umgebung automatisiert werden. Das Prinzip gleicht einer “Wenn-Dann Logik”: Es können bestimmte Events definiert werden, die Aktionen auslösen. Hierzu können Trigger/Filter und Parameter hinterlegt werden, um Einschränkungen zu setzen. Diese Workflows können bearbeitet, deaktiviert und reaktiviert, aber nicht gelöscht werden.

Die Suche nach bestimmten Workflows wird durch die Suchschaltfläche oben rechts erleichtert. Nach Selektieren der Lupe kann ein bestimmter Workflowtitel eingeben werden, nach dem gesucht werden soll.

Es ist möglich, bestimmte Filter auf die aufgelisteten Workflows anzuwenden. Um die Workflows zu filtern, klicken Sie auf die Schaltfläche Filter. Es können mehrere Filter gleichzeitig ausgewählt werden. Der Filter greift dann, wenn das Feld auch tatsächlich ausgewählt wurde (Beispiel Einschränkung auf Prüfobjekttyp “Maschine”). Der Filter greift nicht, wenn der Prüfobjekttyp “Maschine” im Filter ausgewählt wurde, aber kein Workflow explizit darauf eingeschränkt wurde.

Workflow erstellen

Beim Hinzufügen eines neuen Workflows muss ein Titel definiert werden. Der Titel sollte aussagekräftig sein, damit bereits im Menü ersichtlich ist, welche Aufgabe der Workflow erfüllt. Eine Beschreibung kann optional hinzugefügt werden.

Zuerst ist das auslösende Event und danach die anschließende Aktion zu erstellen. Bei Bedarf können auch mehrere auslösende Events und Aktionen hinzugefügt werden. Jedes Event, jede Aktion sowie der gesamte Workflow müssen separat gespeichert werden.

Beispiele unter Workflow Beispiele

Logik

Um einen erfolgreichen und funktionierenden Workflow zu erstellen, muss dieser auch tatsächlich möglich sein. Unlogische Kombinationen können nicht durchgeführt werden. Wurde ein Workflow erstellt, getriggert, aber nicht ausgeführt, so ist dies ein Zeichen dafür, dass dieser fehlgeschlagen ist. In diesem Fall empfiehlt sich eine Kontrolle und Änderung des Workflows auf Korrektheit. Beispiele zu möglichen Fehlern unter: Workflows | Mögliche Fehler oder Unklarheiten

  • Je nach Aktion und Event gibt es unterschiedliche Arten von Filter/Trigger.

    • Beispiel: Prüfobjekttyp, Status

  • Pro Filterart gibt es verschiedene Auswahlmöglichkeiten.

    • Beispiel: Status Abgeschlossen oder Verifiziert

  • Die unterschiedlichen Filterarten addieren sich. Der Workflow wird dann getriggert, wenn beide Filter zutreffen.

    • Beispiel: Prüfobjekttyp Maschinenbau UND Status Abgeschlossen

  • Es ist auch möglich, mehrere Auswahlmöglichkeiten innerhalb eines Filters zu selektieren. Diese stehen in einer Oder-Beziehung, was bedeutet, dass einer der beiden Varianten zutreffen muss, um den Workflow auszulösen. Der Workflow wird dann getriggert, wenn eine der beiden Status zutrifft.

    • Beispiel: Beispiel: Status Abgeschlossen ODER Verifiziert.

  • Wurden verschiedene Auswahlmöglichkeiten bei mehreren Filterarten selektiert, erfolgt eine Kombination aus beiden Logiken.

    • Beispiel: Prüfobjekttyp Maschinen ODER Elektrik UND Status Abgeschlossen ODER Verifiziert

  • Feldwert wenn vorhanden aus Event wiederverwenden (überschreibt obige Auswahl): Ist dieser Fallback aktiviert, so werden Werte eines Events für die Aktion verwendet. Dies ist nur dann möglich, wenn es auch tatsächlich vorherige Werte gibt.

    • Beispiel: Event Checkliste abgeschlossen → Aktion Checkliste erstellen. Toggle (Fallback) ist bei der Aktion beim Filter “Zugewiesen an” aktiviert → neue Checkliste wird automatisch derselben Person/Gruppe vom Event zugewiesen

  • Auf die Berechtigungen achten: Werden aufgrund eines Events Benachrichtigungen verchickt, so erhalten diese nur jene Benutzer mit entsprechenden Berechtigungen.

 

 

 

 

 

 



 

 

Events

Im Abschnitt "Events" sind Schritte zu definieren, die erfüllt sein müssen, um die Aktion auszulösen. Vor der Erstellung von weiteren Events oder Aktionen ist es wichtig das Event zu speichern. Bei der Erstellung von Events müssen die folgenden Informationen angegeben werden:

Obligatorisch

  • Bereich: Der Geltungsbereich definiert die Entität, in der das Event stattfindet. Möglichkeiten: Checkliste, Mangel, Prüfobjekt, PDF, Benutzer, Timer

  • Typ: Der Typ definiert die Änderung der Entität und ist abhängig von der Entität. Möglichkeiten: erstellt, geändert, auslösen

Nicht obligatorisch

  • Filter/Trigger: Mithilfe von Filtern können die Bedingungen spezifiziert werden. Hier kann definiert werden, dass das Event nur unter gewissen Voraussetzungen gültig ist. Je nach gewähltem Typ, erscheinen folgende Auswahlmöglichkeiten:

    • Typ erstellt:

      • Filter: Filtert nach Eigenschaften des Objekts.

        • Beispiel: Prüfobjekttyp Maschinen → Der Workflow wird dann getriggert, wenn der Prüfobjekttyp Maschinen gewählt wurde.

    • Typ geändert:
      Wichtig: Bei der Verwendung von Filtern, wird der Workflow nur dann getriggert, wenn sich Status oder Zuweisung geändert haben.

      • Trigger: Definiert ein Feld, welches auf einen bestimmten Wert geändert werden muss, um den Workflow auszulösen. Diese Bedingung muss erfüllt sein, damit der Workflow ausgelöst wird.

        • Beispiel: Status Verifiziert → Der Workflow wird dann getriggert, wenn sich der Status auf Verifiziert ändert

      • Filter vor Änderung: Filtert nach Eigenschaften des Objekts vor der Änderung. Der Filter vor Änderung findet nur dann Anwendung, wenn sich die Eigenschaft auch wirklich geändert hat. Ist die Eigenschaft vor und nach dem Event gleich oder fehlerhaft, wird der Workflow nicht ausgeführt, da der Filter nicht zutrifft.

        • Beispiel: Status Abgeschlossen → Der Workflow wird dann getriggert, wenn der Status vor Änderung Abgeschlossen war und nach Änderung anders (z. B. verifiziert) ist.

      • Filter nach Änderung: Filtert nach Eigenschaften des Objekts nach der Änderung (Diese Bedingung muss zum Zeitpunkt des Ausführens des Workflows zutreffen).

        • Beispiel: Status Verifiziert → Der Workflow wird dann getriggert, wenn sich der Status nach Änderung auf Verifiziert ändert und vorher anders (z. B. abgeschlossen) war. Ein Filter vor Änderung kann, aber muss nicht definiert werden.

Es ist möglich die Filterarten miteinander zu kombinieren. Voraussetzung dafür ist ebenfalls wieder eine Logik und Sinnhaftigkeit. Fehlerhafte Workflows funktionieren nicht.

Folgende Kombinationen sind möglich:

  • Trigger & Filter vor Änderung

    • z. B. Trigger: Status Abgeschlossen & Filter vor Änderung: Status Offen

  • Filter vor Änderung & Filter nach Änderung

    • z. B. Filter vor Änderung: Status Offen & Filter nach Änderung: Status Abgeschlossen

  • Trigger & Filter nach Änderung

    • z. B. Trigger: Status Abgeschlossen & Filter nach Änderung: Benutzer XY

  • Trigger & Filter vor Änderung & Filter nach Änderung

    • z. B. Trigger: Status Abgeschlossen & Filter vor Änderung: Status Offen & Filter nach Änderung: Status Abgeschlossen

Bereich: Checkliste

  • Typ: erstellt

    • Mögliche Filter: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Checklistenvorlagen, Benutzerdefinierte Felder (Prüfobjekte)

  • Typ: geändert
    Wichtig: Bei der Verwendung von Filtern, wird der Workflow nur dann getriggert, wenn sich Status oder Zuweisung geändert haben.

    • Mögliche Trigger: Status, Zugewiesen an, Geändert von

    • Mögliche Filter vor Änderung: Prüfobjekt(typen), Status, Zugewiesen an, Geändert von, Checklistenvorlagen

    • Mögliche Filter nach Änderung: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Checklistenvorlagen, Scoring, Benutzerdefinierte Felder (Prüfobjekte)

Bereich: Mangel

  • Typ: erstellt

    • Mögliche Filter: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Kategorie, Schweregrad, Benutzerdefinierte Felder (Mängel), Benutzerdefinierte Felder (Prüfobjekte)

  • Typ: geändert
    Wichtig: Bei der Verwendung von Filtern, wird der Workflow nur dann getriggert, wenn sich Status oder Zuweisung geändert haben.

    • Mögliche Trigger: Prüfobjekt, Status, Zugewiesen an, Geändert von, Kategorie, Schweregrad

    • Mögliche Filter vor Änderung: Prüfobjekt(typen), Status, Zugewiesen an, Geändert von, Kategorie, Schweregrad

    • Mögliche Filter nach Änderung: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Kategorie, Schweregrad, Benutzerdefinierte Felder (Mängel), Benutzerdefinierte Felder (Prüfobjekte)

Bereich: Prüfobjekt

  • Typ: erstellt

    • Mögliche Filter: Prüfobjekttypen, Erstellt von, Benutzerdefinierte Felder (Prüfobjekte)

Bereich: PDF

  • Typ: Mangel PDF erstellt

    • Mögliche Filter: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Kategorie, Schweregrad, PDF Protokoll-Profile

  • Typ: Checklisten PDF erstellt

    • Mögliche Filter: Prüfobjekt(typen), Status, Zugewiesen an, Erstellt von, Geändert von, Kategorie, Checklistenvorlagen, PDF Protokoll-Profile

Bereich: Benutzer

  • Typ: erstellt

    • Mögliche Filter: Rollen, Gruppen

Bereich: Timer

  • Typ: auslösen

  • Parameter: Cron timer

Mit der Timer-Funktion können Aufgaben periodisch geplant werden. Dies ist über einen Cron Timer möglich. Die Timer-Funktion kann auf Basis von Minuten, Stunden, Tagen, Wochen oder Monaten eingestellt werden. Der Cron-Trigger bezieht sich immer auf die UTC-Zeitzone, Zeiten sind daher gegebenenfalls umzurechnen (z. B. 12:00 Uhr UTC ist 14:00 Uhr MESZ in Österreich).

Die gewünschte Wiederholung kann entweder direkt im Cron-Format angegeben oder vorab manuell ausgewählt und umgerechnet werden. Bei der Umrechnung der gewünschten Wiederholung gibt es zwei Möglichkeiten:

  • Externer Umrechner: Gewünschte Wiederholung online auswählen und umrechnen

  • Selektierung der gewünschten Wiederholung inklusive automatischer Umrechnung direkt in Testify:

    • Minuten

      • z. B. alle 30 Minuten

    • Stunden

      • z. B. alle 2 Stunden oder immer um 10:00 Uhr AM UTC

    • Täglich

      • z. B. alle 2 Tage oder wochentags inkl. Wunschuhrzeit (z. B. 10:00 Uhr AM UTC)

    • Wöchentlich

      • Angabe der gewünschten Wochentage z. B. nur Montags, Montag & Freitag oder Montag-Samstag inkl. Wunschuhrzeit (z. B. 10:00 Uhr AM UTC)

    • Monatlich

      • Angabe des genauen Tages (z. B. 4. Tag pro Monat) oder

      • Letzter Tag des Monats oder

      • Letzter Wochentag des Monats oder

      • Angabe der Tage for Monatsende (z. B. 2 Tage vor Monatsende)

      • inkl. Wunschuhrzeit (z. B. 10:00 Uhr AM UTC)

Beispiele

Aktionen

Im Abschnitt "Aktionen" wird die Aktion definiert, die durch das auslösende Event getriggert wird. Vor der Erstellung von weiteren Aktionen oder dem Speichern des Workflows ist es wichtig die Aktion zu speichern. Da manche Aktionen erst nach dem Speichern eines Events freigeschalten werden, empfiehlt es sich Aktionen erst als zweiten Schritt anzulegen.

Beim Erstellen von Aktionen müssen folgende Informationen angegeben werden:

  • Bereich: Der Bereich definiert, welche Aktion ausgelöst werden soll.

  • Typ: Der Typ definiert die Änderung der Entität.

  • Parameter: Hier müssen Parameter für die ausgelöste Aktion definiert werden (wie Prüfobjekte, Checklistenvorlagen usw.). In diesem Abschnitt können die Werte, die bereits oben in "Filter" definiert wurden, einfach wiederverwendet werden, indem der Schalter "Feldwert wenn vorhanden aus Event wiederverwenden" ausgewählt wird.

    • Die Definition aller Parameter ist in diesem Abschnitt obligatorisch.

Bereich: Checkliste

Bereich: Mangel

  • Typ: erstellen

    • Obligatorische Parameter: Zugewiesen an, Erstellt von, Kategorie, Schweregrad, Fälligkeitsdatum

    • Optionale Parameter: Prüfobjekt, Titel, Beschreibung

Bereich: Webhook

  • Typ: auslösen

    • Obligatorische Parameter: URL

    • Optionale Parameter: Kennung, Timeout für HTTP-Requests in Sekunden (Standard ist 20), HTTP Status Codes bei erfolgreichem Request. Andere Codes führen zu mehreren Sendeversuchen.

    • Workflow Beispiele | Beispiel: Aktion Webhook

Bereich: PDF

Nur bei Events mit Bereich Checkliste oder Mangel möglich.

Bereich: Benachrichtigung

Bereich: Kalendereintrag

  • Typ: senden

    • Obligatorische Parameter: Senden an (einem spezifischen Benutzer bzw. Benutzer einer Gruppe oder dem Benutzer, dem das Event zugewiesen ist oder dem Benutzer, der das Event erstellt hat)

    • Optionale Parameter:

      • Abweichung zum Fälligkeitsdatum in Tagen (Mehr oder Weniger z. B. +1)

      • Abweichung zum Fälligkeitsdatum in Stunden (Mehr oder Weniger z. B. -1)

      • Dauer des Termins in Minuten (z. B. 30 Min)

    • Workflow Beispiele | 13) Kalendereintrag bei Checklistenfälligkeit

  • Hinweise

    • Es empfiehlt sich hier, gleich zwei Events hinzuzufügen (Typ erstellt und geändert), damit man nicht nur bei Erstellung einen Kalendereintrag erhält, sondern auch eine Aktualisierung dessen bei Update des Events.

    • Der Termin wird nur dann aktualisiert, wenn sich das Fälligkeitsdatum oder zugewiesene Benutzer ändert.

      • Wird das Event später einem neuen Benutzer zugewiesen, erhält der ursprüngliche Benutzer eine Absage des Termins im Kalender.

Bereich: Prüfobjekt

  • Typ: ändern

    • Parameter:

      • Prüfung zu benutzerdefinierten Feld verlinken

        • Checklistenvorlage auswählen

          • Prüfung auswählen

            • Benutzerdefiniertes Feld von Prüfobjekt auswählen

  • Workflow Beispiele | 14) Prüfergebnis in benutzerdefiniertes Feld eines Prüfobjekts

  • Hinweise

    • Wird eine Checkliste ausgefüllt und abgeschlossen, wird das Prüfergebnis im benutzerdefinierten Feld des Prüfobjekts gespeichert.

    • Der Typ des benutzerdefinierten Feldes sowie der Prüfung müssen übereinstimmen (zum Beispiel numerisch und numerisch).

Verzögerung

Um Aktionen erst zu einem späteren Zeitpunkt auszuführen, können Verzögerungen hinzugefügt werden.

Workflow bearbeiten / deaktivieren

Nach der Erstellung des Workflows kann dieser durch Klicken auf das Kontextmenü (die drei Punkte) in der oberen rechten Ecke des Workflows bearbeitet oder deaktiviert/aktiviert werden.

Workflow-Historie

Workflows haben eine Historie, bei der alle bisherigen Schritte angezeigt werden. Diese Funktion ermöglicht es, die erfolgreichen und fehlgeschlagenen Ausführungen aller Workflows zu überprüfen. Für jeden Ausführungsversuch wird ein eigener Eintrag mit allen relevanten Informationen erstellt. Um eine transparente Fehlersuche zu gewährleisten, können Filter gesetzt werden. Ebenso wird angezeigt wann ein Workflow aktiviert/deaktiviert wurde und ob dies automatisch oder manuell durch eine Person geschehen ist.

Die Workflow-Historie kann durch Klicken auf das Kontextmenü (die drei Punkte in der rechten Ecke) angezeigt werden. Dies ist entweder in der Workflowübersicht möglich, aber auch innerhalb eines Workflows:

Durch Auswahl des gewünschten Eintrags wird die Historie angezeigt:

Alle wichtigen Informationen sind auf einen Blick ersichtlich. Durch das Link-Icon auf der rechten Seite neben dem Text können die einzelnen Punkte erweitert und weitere Details angezeigt werden:

Bei der Verwendung von Verzögerungen gibt es abhängig vom Status folgende Möglichkeiten, die angezeigt werden:

  • Offene/Geplante Aktionen: Datum und Zeit der Auslösung" sowie "Datum und Zeit der geplanten Ausführung"

  • Erfolgreiche und fehlgeschlagene Aktionen: “Datum und Zeit der Ausführung"

  • Deaktivierter Workflow “"Der Workflow wurde während der Verzögerung deaktiviert"

  • Workflow stimmt nicht mit dem Ereignis überein: "Der Filter nach der Verzögerung entsprach nicht den Anforderungen"

Mögliche Fehler oder Unklarheiten

Events

Fehlender oder falscher Auslöser für Event

Bei der Verwendung von Filtern, wird der Workflow nur dann getriggert, wenn sich Status oder Zuweisung geändert haben.

  • Fehlerhaftes Event: Workflow für geänderte Checklisten, die beim Filter vor Änderung auf eine Checklistenvorlage einschränken.

    • Bereich: Checkliste

    • Typ: Geändert

    • Filter vor Änderung: Eine Checklistenvorlage
      → Da sich die Checklistenvorlage nicht ändern wird, wird der Workflow nie ausgelöst werden. Anwender könnten meinen, dass sie jede Checklistenänderung als Event triggern. Da sich aber die Checklistenvorlage nicht ändern wird, wir der Workflow nicht ausgelöst.

  • Korrigiertes und funktionierendes Event

    • Bereich: Checkliste

    • Type: Geändert

    • Filter vor Änderung: Status Abgeschlossen, Verifiziert

  • Trigger Zugewiesen an Person X ist nur dann möglich, wenn sich der Wert auch tatsächlich geändert hat.

    • Ist die Eigenschaft vor und nach dem Event gleich oder fehlerhaft, wird der Workflow nicht ausgeführt, da der Filter nicht zutrifft.

Fehlerhafte oder Unlogische Filtersetzung

  • Event: Checkliste erstellt → Filter Status Verifiziert

    • Eine neu erstellte Checkliste ist immer im Status Offen. Der Filter Status Verifiziert ergibt hier keinen Sinn.

  • Trigger Status Abgeschlossen und Filter nach Änderung Status Verifiziert

    • Soll der Workflow beim Status Abgeschlossen ODER Verifiziert getriggert werden, so ist dies mittels Filter nach Änderung abzubilden.

  • Häufiger Unklarheit: Event → Checkliste geändert → Status in Bearbeitung

    • Sobald eine Checkliste gestartet wird, ist die Checkliste im Status in Bearbeitung. Bereits dann wird der Workflow ausgelöst und nicht erst beim Verlassen.

Beispiele unter Workflow Beispiele

Related content