Neue Benutzer mit Power Apps erstellen (3. Teil)

Ok Team, unsere lange, mühsame Power Apps Reise ist vorbei. Wir haben es geschafft! Ich habe eine Power App mit vollständigen Funktionen, die es auch nicht-technischen, nicht-IT-Kollegen ermöglicht, neue Benutzer anzulegen und sie in den Gruppen zuzuweisen. Mit Version 1 war das nicht möglich, weil Microsofts eingebaute Konnektoren für Power Apps nicht ausreichen (siehe Teil 1). Deshalb habe ich euch in Teil 2 gezeigt, wie du benutzerdefinierte (d. h. teure) Konnektoren für die Graph API erstellst, die mir alle benötigten Azure AD-Attribute liefern.

Demo

Option 1: vorhandenen Benutzer als Vorlagenbenutzer verwenden

Werfen wir einen Blick auf die App und sprechen wir über einige der Funktionen. Zunächst bietet die App die Möglichkeit, einen bestehenden Benutzer als Vorlage zu verwenden, indem sie die Benutzergruppen und Azure AD-Attribute dieser Vorlage aufruft, dann kann der Endbenutzer der App die Felder nach seinen Wünschen bearbeiten und auf „Erstellen“ klicken.

An animated GIF demonstrating the Power App for creating a user from another "template" user — Ich musste das Formular von Hand erstellen, da die „Formulare“ in Power Apps keine Sammlungen als Datenquelle unterstützen 😓

Schau mal auf der sexy Fehlerprüfung bei den Pflichtfeldern 😎. Die App prüft, dass KEINE Mail-Adressen im gesamten Tenant doppelt vorhanden sind, und sie bestätigt natürlich, dass die Adressen ein gültiges Format haben und die verfügbaren Domänennamen des Tenants verwenden. Außerdem wird automatisch ein komplexes Passwort generiert und auf „Zurücksetzen erforderlich“ gesetzt. Der Endbenutzer der App kann auch die Gruppen überprüfen, denen der neue Benutzer auf der Grundlage der aktuellen Gruppen des Vorlagenbenutzers zugewiesen werden soll.

Aber hat es funktioniert?

An animated GIF demonstrating that, yes, the user in the previous GIF was created successfully. — Hier kann man sehen, dass der alte Johnny Helpdesk erfolgreich mit all seinen Attributen und Mailadressen erstellt wurde

Option 2: Mit einem leeren Formular von vorne beginnen

Die andere Möglichkeit, neue Benutzer anzulegen, besteht darin, mit einem leeren Formular zu beginnen und alles von Grund auf auszufüllen. So sieht das aus:

An animated GIF demonstrating how one can create a user from a completely blank form.

In diesem Beispiel beginnt der Endbenutzer mit einem leeren Formular und muss nur die erforderlichen Felder ausfüllen, bevor der Benutzer erstellt werden kann. Auf der linken Seite befindet sich eine Liste ALLER Gruppen des Mandanten, denen der neue Benutzer zugewiesen werden kann.

Download

Hier ist ein Link zu einer exportierten Version der App im ZIP-Format mit den erforderlichen Konnektoren. Solange Sie die benutzerdefinierten Konnektoren nicht erstellt haben, wird der Import meines Erachtens fehlschlagen, aber Sie können mich gerne über das Kontaktformular kontaktieren, wenn ich Ihnen helfen kann. Hier ist die Importanleitung für Power Apps aus der Dokumentation von Microsoft.

Einschränkungen (Die Features, keine Bugs hier)

Nun, es ist nicht perfekt. Es gibt definitiv einige potenzielle Verbesserungen, die ich mir vorstellen kann, aber ich bin zu faul, um sie aus Spaß zu implementieren, und es gibt einige Einschränkungen durch Power Apps und Microsoft Graph.

Die App validiert die eingegebenen neuen E-Mail-Adressen nicht anhand ALLER E-Mail-Adressen in Exchange Online, wie z. B. Verteilergruppen und E-Mail-aktivierte Sicherheitsgruppen, da diese von Microsoft Graph nicht sofort verfügbar sind.
Die akzeptablen Domänennamen für die Überprüfung von E-Mail-Adressen sind in den Power Apps fest kodiert. Es wäre sicherlich möglich, dies dynamisch zu überprüfen, aber ich bin zu faul, und mal ehrlich gesagt, wie oft fügt man seinem Tenant eine neue Mail-Domäne hinzu?
Wenn der Endbenutzer auf „Create“ klickt, erstellt die App den Benutzer natürlich in Azure AD, muss dann aber warten, bis dieser Benutzer „verfügbar“ ist, um im zweiten Schritt zu Gruppen hinzugefügt zu werden. Ich erreiche diese Wartezeit durch eine 45-sekündige versteckter Timer, aber 45 Sekunden sind eine lange Zeit für dem Endnutzer zu warten. Es gibt sicherlich eine Lösung, bei der mehrere Timer in 15er-Schritten herunterzählen, aber auch hier bin ich zu faul. Auch die Tatsache, dass es in Power Apps keinen „while“- oder „wait“-Befehl gibt… ooofff.
Bei den Feldern businessPhones (Office Phone) und otherMails (Secondary Mail) musste ich schummeln. Wenn der Endbenutzer die Felder leer lässt, musste ich ein leeres Unicode-Zeichen eingeben, da die Graph API hier keine leeren Einträge zulässt, da es sich um Arrays in Azure AD handelt. Ich bin sicher, dass es eine bessere Methode gibt, aber auch hier Faulheit.
Apropos diese beiden Arrays in Azure AD, eine coole zukünftige Funktion wäre es, die Textfelder in Kombinationsfelder zu verwandeln, in denen der Endbenutzer mehrere „otherMails“ hinzufügen könnte, da neue Benutzer mehrere SMTPProxyAdressen haben können.
Die Methode zur Erstellung eines „Vorlagenbenutzers“ sollte eine Option zum Hinzufügen anderer, nicht in der Vorlage enthaltener Gruppen für den neuen Benutzer bieten.
Schließlich gibt es in der Anwendung keine Lizenzverwaltung. Das wäre eine nette Funktion für einen dritten Screen, oder man kann einfach dynamische Gruppen in Azure AD für die Lizenzzuweisung verwenden, was man ohnehin tun sollte…

Fazit

Nun, ich hoffe, das hilft jemandem. Es waren mehr als 2 Wochen Arbeit für mich, aber ich habe dabei eine Menge über Power Apps gelernt. Leider glaube ich nicht, dass Power Apps der richtige Weg für diese Art von Prozess ist, da für die benutzerdefinierten Konnektoren Premiumlizenzen erforderlich sind. Es ist immer schön, wenn man den nicht-technischen Kollegen ein wenig von der Arbeit der IT-Mitarbeiter abnehmen kann, aber die Premium-Lizenzen für Power Apps sind schwer an den Chefs zu verkaufen.