Das Fundament: Wie SharePoint-Liste und Power App das Rückgrat der Nutzerinventur bilden

In meinem Portfolioartikel zu meiner Nutzerinventur Automatisierung, bin ich darauf eingegangen, was das Problem war und wie ich es gelöst habe. Nun möchte ich tiefer auf die einzelnen Komponenten der Lösung eingehen.

Jedes automatisierte System ist nur so gut wie seine Datenbasis. Wenn die Daten falsch sind, wenn Felder fehlen, wenn Berechtigungen nicht stimmen, dann scheitert die Automatisierung nicht an der Logik, sondern am Fundament. Deshalb war der erste Schritt dieses Projekts nicht der erste Flow, sondern die SharePoint-Liste.

Die SharePoint-Liste: Mehr als ein Datenspeicher

Die Liste hat eine Doppelrolle. Sie speichert die Daten und steuert gleichzeitig den Prozess. Das zweite ist das Entscheidende.

Die Spaltenstruktur

Jede Spalte wurde bewusst gewählt. Kein Freitext, wo ein strukturierter Typ möglich ist.

Spalte	Typ	Warum dieser Typ?
System	Auswahl	Nur vordefinierte Systeme möglich, kein Tippfehler-Risiko
Name	Person	Nur gültige Personen aus dem Verzeichnis, automatische E-Mail-Adresse
Status	Auswahl	Prozesssteuerung, jeder Flow filtert auf seinen Status-Wert
nächste_Inventur	Datum	Filterbar, direkt vergleichbar mit Today()
Endtermin	Datum	Fristüberwachung im Flow
Reminder gesendet	Ja/Nein	Verhindert doppelte Erinnerungsmails
Löschkandidat	Ja/Nein	Klares Flag für den Lösch-Flow
Antwortdatum	Datum	Nachvollziehbarkeit, wann wurde geantwortet

So sieht die reale Sharepointliste in ihrem Aufbau aus. Hier gefüllt mit Testdaten.

Indexierung: Das 5.000-Einträge-Problem lösen

SharePoint-Listen haben ein bekanntes Limit. Wenn eine Liste mehr als 5.000 Einträge hat, können ungefilterte Abfragen fehlschlagen. Die Lösung ist Indexierung. SharePoint erstellt dann einen internen Index für diese Spalten, ähnlich wie ein Datenbankindex. Abfragen über indexierte Spalten sind schneller und umgehen das Limit.

Indexiert wurden alle Spalten, über die die Flows filtern: Status, nächste_Inventur und Name. Das ist keine Optimierung für später, das ist eine Grundvoraussetzung für einen stabilen Betrieb.

Das Berechtigungskonzept

Berechtigungen sind ein Thema, das viele Citizen Developer zu spät angehen. Hier war es von Anfang an eingeplant.

• Admin-Gruppe: Vollzugriff auf die Liste. Neue User eintragen, Fehler korrigieren, Löschkandidaten verwalten. Aktuell nur der KeyUser.
• User-Gruppe: Nur Lesezugriff. Das Programmplanungsteam kann die Liste einsehen, aber nicht verändern.

Der Vorteil dieser Gruppenstruktur: Bei Personalwechsel wird nur die Gruppe angepasst, nicht jede einzelne Berechtigung. Das spart Zeit und verhindert Fehler.

Status als Prozesssteuerung

Der Status-Wert ist das Herzstück der Prozesssteuerung. Jeder Wert hat eine präzise Bedeutung und jeder Flow filtert ausschließlich auf seinen eigenen Status.

Status	Bedeutung im Prozess
Aktiv	User ist aktiv, Inventur noch nicht fällig oder bereits abgeschlossen
im Flow Prozess	Inventurtrigger läuft, Schutz vor Doppelverarbeitung
Offen	Inventurtrigger-Timeout, User wartet auf Reminder
im Reminder Prozess	Reminder-Flow läuft
im Löschprozess	Lösch-Flow läuft
gelöscht	User wurde aus der Inventurliste entfernt

Die Power App: Datenpflege ohne Fehlerquellen

Die Power App ist die Eingabemaske für die manuelle Datenpflege. Sie ist direkt in SharePoint eingebettet und für alle Berechtigten zugänglich. Wer einen neuen User einträgt oder einen bestehenden Eintrag anpasst, tut das über die App, nicht direkt in der Liste.

Das hat einen einfachen Grund: Die App kann Fehleingaben strukturell verhindern. Die Liste kann das nicht.

Hier die Power App, wie sie in Sharepoint direkt integriert wurden ist. Hier musste ich einige interne Daten schwärzen

Der inaktive Speicherbutton

Das auffälligste Feature der App ist gleichzeitig das einfachste: Der Speicherbutton ist nur sichtbar, wenn alle Pflichtfelder ausgefüllt sind. Solange System oder Name leer sind, gibt es keinen Button zum Klicken.

Die Logik dafür liegt in App.Formulas, dem zentralen Bereich für wiederverwendbare Formeln in Power Apps:

// Prüfung ob ein System ausgewählt wurde
system_io = !IsBlank(DC_Systemauswahl.Selected);

// Prüfung ob eine Person ausgewählt wurde
name_io = !IsBlank(DC_User.Selected);

// Prüfung ob das Nachtragsdatum logisch korrekt ist
nachtragen_datum_io = If(Nachtragen_Datum.SelectedDate <= Today(), true, false);

// Speicherbutton Ein-Ausblenden
speichern_io = system_io && name_io && nachtragen_datum_io;

Der Speicherbutton hat dann nur noch eine einzige Eigenschaft: Visible = speichern_io. Wenn alle drei Bedingungen erfüllt sind, erscheint der Button. Wenn eine fehlt, bleibt er unsichtbar.

Der Vorteil von App.Formulas: Wenn später eine weitere Prüfung hinzukommt, wird nur speichern_io erweitert. Der Speicherbutton reagiert automatisch, ohne dass er angefasst werden muss.

Was bedeuten diese Formel-Bestandteile genau?

Damit die Logik hinter der Validierung im Alltag stabil funktioniert, nutzen wir eine Handvoll zentraler PowerFX-Befehle, die dir aus der klassischen Tabellenkalkulation vielleicht schon bekannt vorkommen:

Today(): Dieser Befehl liefert uns ganz pragmatisch das aktuelle Systemdatum des heutigen Tages frei Haus.

IsBlank(): Diese Funktion prüft, ob ein Steuerelement oder ein Datenfeld komplett leer ist. Wenn kein Wert vorhanden ist, liefert sie als Rückgabe ein Wahr (True) zurück.

Das Ausrufezeichen (!): Das Voranstellen eines Ausrufezeichens kehrt das logische Ergebnis einer Funktion ins Gegenteil um (Negation). Aus IsBlank() (ist leer) wird durch das ! also im Handumdrehen die Bedingung „Das Feld darf nicht leer sein“.

Die doppelten kaufmännischen Und-Zeichen (&&): Sie repräsentieren die logische UND-Verknüpfung. Jede einzelne der damit verknüpften Variablen muss zwingend Wahr sein, damit auch das Gesamtergebnis am Ende auf Wahr gesetzt wird und der Speicher-Button erscheint.

Der Parameter .Selected: Über diesen Zusatz greift die App auf den aktuell ausgewählten Datensatz aus deinen Dropdowns oder Personen-Suchfeldern zu. Wurde vom Nutzer nichts ausgewählt, bleibt dieser Bereich leer, was wir wiederum perfekt mit unseren Prüfungen abfangen können.

If(): Dieser Block arbeitet exakt wie die klassische Excel-Formel WENN(). Die Syntax lautet immer nach demselben Prinzip: If(Bedingung, Wert wenn Wahr, Wert wenn Falsch).

Die automatische Inventurdatum-Berechnung

Das nächste Inventurdatum wird automatisch berechnet. Der User muss es nicht eingeben. Der Standard ist heute plus 365 Tage, weil davon ausgegangen wird, dass ein neu eingetragener User ab heute aktiv ist.

Für Nachtragungen gibt es eine Ausnahme. Wenn ein User rückwirkend eingetragen wird, kann ein abweichendes Datum angegeben werden. Die App berechnet das Inventurdatum dann auf Basis dieses Datums:

// Inventurdatum berechnen

inventur_datum =

    If(Nachtragen_Checkbox.Value,

        DateAdd(Nachtragen_Datum.SelectedDate, 365, TimeUnit.Days),
        DateAdd(Today(), 365, TimeUnit.Days)

    );

Die neuen Werkzeuge für unsere Datumsberechnung

Um das zukünftige Inventurdatum präzise in die Zukunft zu projizieren, nutzen wir zwei aufeinander abgestimmte Befehle, die das Rechnen mit Zeitangaben in Power Apps zum Kinderspiel machen:

TimeUnit.Days: Hiermit definierst du die Maßeinheit für deine Berechnung. Da wir flexibel in Tagen rechnen wollen, teilen wir der DateAdd()-Funktion über diesen Zusatz unmissverständlich mit, dass es sich bei der übergebenen Zahl (365) um Tage und nicht etwa um Monate oder Jahre handelt.

DateAdd(): Diese Funktion ist dein mathematisches Werkzeug für Kalenderdaten. Sie nimmt ein bestehendes Ausgangsdatum und addiert eine von dir definierte Anzahl von Zeiteinheiten oben auf. In unserem Fall sorgt sie dafür, dass entweder auf den heutigen Tag oder auf ein frei gewähltes Nachtragsdatum die exakte Spanne für das nächste Jahr aufgeschlagen wird.

Das Delegierungsproblem: Eine ehrliche Einschränkung

Power Apps hat ein bekanntes Konzept namens Delegierung. Nicht alle Filter-Funktionen können an SharePoint delegiert werden. Nicht-delegierbare Filter werden lokal ausgeführt, aber nur auf den ersten 500 Einträgen der Liste.

In der aktuellen Version kann die Suche in der App nur nach dem Nachnamen filtern. Eine Suche nach Vornamen oder nach dem System funktioniert nicht wie erwartet, weil diese Filter nicht delegierbar sind, sobald ich diese miteinander kombinieren will. Das ist eine bekannte Einschränkung, die in einer späteren Version adressiert wird. Für den MVP ist die Nachnamen-Suche ausreichend.

Das Lernprinzip: Wenn ein Filter in Power Apps nicht wie erwartet funktioniert, prüfe zuerst, ob die verwendete Funktion mit der jeweiligen Datenquelle delegierbar ist. Microsoft dokumentiert das für jede Kombination.

Weiterführende Artikel zur Nutzerinventur

Von der Zettelwirtschaft zum vollautomatischen System: Wie ich die Nutzerinventur in 8 Stunden neu erfunden habe
Die digitale Fabrikhalle: Wie drei spezialisierte Power Automate Flows einen Prozess vollständig automatisieren
Das Handwerk hinter dem Code: Warum Dokumentation der wahre Hebel für professionelles Citizen Development ist