Flowauslösung per E-Mail, native Flow-Trigger für Alarme und Ereignisse und vieles mehr!
In diesem Release lag ein Großteil von unserem Fokus auf die Erweiterung des Flows. Durch das gesammelte Feedback hat sich schnell herausgestellt, dass eine Integration in das System über E-Mail für viele Administratoren sehr hilfreich wäre - das liefern wir in diesem Release. Somit ist jetzt z.B. auch eine Alarmauslösung durch E-Mail möglich.
Außerdem haben wir einige Kleinigkeiten verbessert, die beim Umstieg auf ein neues Handy die Übernahme der jeweiligen App verbessern.
In der neuen Version von GroupAlarm können Sie mithilfe der Flows eigene HTTP-Aufrufe ausführen, um so zum Beispiel Ihre eigenen APIs über einen ausgelösten Alarm informieren. Dazu können Sie neben der URL auch eigene Header-Felder und den Body konfigurieren.
Mit einem HTTP Trigger lassen sich Flows nun auch mit einem HTTP-Aufruf von Ihrer Seite auslösen. Nutzen Sie zusätzlich die Möglichkeit eigene Werte aus den Query-Parametern oder Header als Variablen zu speichern. Ihre Variablen können Sie dann in nachfolgenden Funktionen als Input verwenden, um so zum Beispiel einen Alarm mit der aktuellen Temperatur eines Sensors auszulösen.
Flows können nun auch durch eingehende E-Mails ausgelöst werden. Verwenden Sie dazu den neuen Trigger “E-Mail empfangen” und legen Sie - falls gewünscht - die zugelassenen Absender fest. In der Konfiguration wird Ihnen eine eindeutige E-Mail-Adresse angezeigt, an welche Sie nun E-Mails versenden können. In den folgenden Schritten des Flows können dann die Details der erhaltenen E-Mail weiterverarbeitet werden.
Um besser nach Funktionen für den Flow zu suchen, wurde die Liste der Funktionen um eine Suchleiste erweitert. Zudem werden die einzelnen Funktionen nun auch mit ihren Kategorien sortiert und gesammelt angezeigt.
Es wurde die Möglichkeit geschaffen, Flows zu pausieren. So kann jederzeit ein Flow pausiert werden, der aktuell nicht gebraucht wird.
Das Verhalten bei der Alarmierung einzelner Teilnehmer wurde dem Verhalten aller anderen Alarm-Ressourcen bei einem aktiven Schichtplan angeglichen. Das bedeutet, dass ein einzelner Teilnehmer nicht mehr in jedem Fall alarmiert wird, sondern nur dann, wenn entweder kein Schichtplan aktiv ist oder der Teilnehmer einer Schicht in einem aktiven Schichtplan zugewiesen ist. Dieses Verhalten wird auch bei der Alarmierung aller Teilnehmer angewendet.
Die verwendeten Icons innerhalb der Feedbackübersicht eines einzelnen Teilnehmers im Alarm wurden ausgetauscht, sodass die Icons zur Anzeige der Nachrichtenzustellung nicht mit den Icons zur Zu-/Absage eines Teilnehmers vertauscht werden können.
Innerhalb von großen Organisationen konnte es beim Laden der Pagerverwaltung zu Performanceproblemen kommen. Diese wurden nun behoben, sodass die Liste aller Pager mit ihren Teilnehmern wieder gewohnt schnell angezeigt wird.
Bisher blieb nach einer abgelaufenen Testversion der Hinweis auf diese im Ausklappmenü des Profils bestehen. Dieser kann nun mit einem einfachen Klick dauerhaft ausgeblendet werden.
Beim Teilnehmerimport über eine CSV-Datei werden entsprechend benannte Spalten nun automatisch zugeordnet. Die genaue Benennung der Spalten kann der Dokumentation entnommen werden.
Es wurden weitere Trigger aus den Bereichen Alarme und Ereignisse hinzugefügt. So kann ein Flow nun gestartet werden, wenn ein Alarm oder ein Ereignis gestartet oder geschlossen wird.
Organisationsweite API-Tokens können nun, ähnlich zu den Personal Access Tokens, nur noch einmalig bei ihrer Erzeugung angezeigt werden. Anschließend kann ein solcher Token nur noch regeneriert werden. Dabei bleiben Name und Einstellungen erhalten, allerdings ändert sich der geheime Schlüssel. Bestehende API-Tokens können natürlich weiterhin verwendet werden und verlieren nicht ihre Gültigkeit.
Beim Schließen eines Ereignisses werden nun auch automatisch alle Alarme innerhalb des Ereignisses geschlossen.
Bisher wurden zum Abruf des Gerätefeedbacks für einen einzelnen Teilnehmer zusätzlich die ID der Einheit und des Labels verwendet, in denen der Teilnehmer alarmiert wurde. Dies hat zu Problemen geführt, falls der Teilnehmer durch Priorisierungen oder Vertretungen in eine andere Einheit versetzt oder ihm ein anderes Label zugewiesen wurde. Daher werden nun Einheiten und Labels beim Abruf des Feedbacks ignoriert, sodass jedes Feedback für den jeweiligen Teilnehmer im gewählten Alarm angezeigt werden.
Organisationen können nun nur noch dann endgültig gelöscht werden, wenn für sie keine aktive Abrechnung mehr besteht. Aktive Organisationen müssen daher nun zunächst die Abrechnung kündigen und den nächsten Rechnungszyklus abwarten, bevor eine Löschung möglich ist.
