Version 3.4 erlaubt die Auslösung von Flows durch IMAP-Postfächer, das Auslesen von XML-Dokumenten und verbessert die Geschwindigkeit der mobilen Apps.
Innerhalb der Flows lassen sich nun IMAP-Postfächer als Trigger verwenden. So wird ein neuer Flow gestartet, wenn eine neue E-Mail im konfigurierten IMAP-Postfach empfangen wird. Konfigurieren Sie zudem erwartete Anhänge, wie zum Beispiel Einsatzdetails im XML-Format, damit diese in nachfolgenden Funktionen verwendet werden können und ein Alarm mit den im Anhang enthaltenen Details ausgelöst wird.
Innerhalb der Flows können Sie nun XML-Dokumente verarbeiten. Lesen Sie einzelne Werte oder Listen des Dokuments in eigene Variablen aus, die Sie in nachfolgenden Funktionen des Flows verwenden können.
In der Teilnehmerübersicht kann man nun direkt die Labels eines Teilnehmers bearbeiten, ohne in die Zuordnungsmatrix wechseln zu müssen.
Wir haben innerhalb der mobilen Apps das Anmeldeverfahren umgestellt, sodass diese, gerade bei größeren Alarmen, deutlich schneller reagieren und Ihre Rückmeldung ohne Verzögerung abgesendet und verarbeitet werden kann. Bestehende Teilnehmer stellen wir automatisch auf dieses Verfahren um. Es ist kein Handeln Ihrerseits notwendig.
In seltenen Fällen konnte es vorkommen, dass ein Alarm bereits geschlossen wurde, Teilnehmer allerdings weiterhin als “nicht verfügbar” in der Teilnehmerliste angezeigt wurden. Dieses Problem haben wir nun behoben.
Im Bereich “Einstellungen” Ihres Profils können Sie nun eine Übersicht der aktiven Sitzungen einsehen. Dort sehen Sie auf einen Blick, welches Gerät sich wann von welcher IP-Adresse eingeloggt hat und wann GroupAlarm zuletzt verwendet wurde. Falls Sie eine Sitzung nicht erkennen, können Sie diese jederzeit mit einem Klick auf die Schaltfläche beenden. Das Gerät wird dann abgemeldet.
Innerhalb der Abrechnung wird nun nach der Kündigung einer Organisation zusätzlich zum Zeitpunkt der Deaktivierung auch der Zeitpunkt der Kündigung selbst angezeigt.
Bei der Alarmierung von zwei Labels, die sich jeweils gegenseitig als Vertretungslabel eingetragen haben, wurden in jedem Alarmierungsschritt erneut die benötigte Anzahl der Teilnehmer alarmiert. Dadurch wurden in großen Alarmen so viele Teilnehmer alarmiert, dass ein Abschluss der Alarmierung nicht mehr möglich war. Diesen Fehler haben wir nun behoben.