Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Power-Apps-Formulare für SharePoint: Warum Listenformulare im Betrieb scheitern und wie sie zuverlässig werden (KI-Synchronfassung)

Transcript

Power-Apps-Formulare für SharePoint: Warum Listenformulare im Betrieb scheitern und wie sie zuverlässig werden (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:00
  Bereit für 10 Tage voller Microsoft 365 Co-Pilot, KI, Azure und den Vordenkern der Arbeitswelt von morgen hoch.
• 0:07
  Diesen Januar ist die M365Con zurück und wir legen noch eine Schippe drauf.
• 0:12
  Erleben Sie Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt.
• 0:18
  Keine generischen Folien, kein Endless Buzz-Widming.
• 0:21
  Wir widmen uns den echten Herausforderungen.
• 0:23
  Co-Pilot Studio, KI-Agenten, Fabrik, Sicherheit, Governance und Automatisierung.
• 0:28
  Ob IT-Profi-Entwickler oder Führungskraft-A-Skip-Sessions, die genau auf Sie zugeschnitten sind.
• 0:35
  An 10 vollen Tagen können Sie Technologien erkunden und sich mit einer globalen Community vernetzen.
• 0:40
  Seien Sie live dabei und nehmen Sie praxisnahe Erkenntnisse mit in Ihr Unternehmen.
• 0:45
  Januar 2027, 10 Tage, eine Microsoft Community.
• 0:49
  Die Anmeldung ist jetzt eröffnet.
• 0:51
  Sichern Sie sich noch heute Ihren Platz.
• 0:54
  Das ist m3fumundestekon.net
• 1:00
  Melden Sie sich jetzt unter m3fumundestekon.net an und wir sehen uns live im Januar.
• 1:05
  Ihr SharePoint-Formular sieht in Power-Apps großartig aus, bis es das plötzlich nicht mehr tut.
• 1:08
  Plötzlich speichert die Schaltfläche nicht mehr korrekt.
• 1:10
  Die Feldvalidierung verhält sich seltsam und die Performance fühlt sich an wie CR-Schlamm.
• 1:14
  Ist die Wahrheit.
• 1:15
  Power-Apps-Formulare wirken oft täuschend einfach, bergen aber Fallstricke, die die meisten Profis kalt erwischen.
• 1:21
  Heute sehen Sie genau, wo diese Fallstricke in einem realen Anfrageformular auftreten
• 1:24
  und mit welchen Schritt-für-Schritt-Techniken Ihr Formular nicht nur gut aussieht, sondern auch zuverlässig arbeitet.
• 1:28
  Warum einfache Anfänge zu schwierigen Problemen wären.
• 1:33
  Sie klicken auf den kleinen Button mit Power-Apps anpassen
• 1:35
  und innerhalb von Minuten wirkt Ihr SharePoint-Listen-Formular wie verwandelt.
• 1:39
  Plötzlich sind es nicht mehr nur Kästchen und Beschriftungen.
• 1:41
  Es ist eine elegante Anwendung mit Dropdowns, Schaltern und einem frischen Design.
• 1:44
  Es fühlt sich an, als hätten Sie in Rekordzeit eine App gebaut.
• 1:46
  Das ist das Aufregende daran.
• 1:48
  Doch die Begeisterung verfliegt meist schnell,
• 1:50
  da diese schnellen Erfolge oft nicht überdauern,
• 1:51
  sobald das Formular live geht und echte Nutzer damit arbeiten.
• 1:54
  Oh.
• 1:55
  Der Grund, warum es sich anfangs so einfach anfühlt,
• 1:57
  ist, dass Power-Apps einen visuellen Ansatz fördert.
• 2:00
  Sie ziehen ein Steuerelement auf den Bildschirm,
• 2:02
  setzen eine Eigenschaft mit einer Formel, die fast wie in Excel aussieht
• 2:04
  und es reagiert genau wie erwartet.
• 2:06
  Innerhalb einer einzigen Sitzung können Sie Felder ausblenden,
• 2:09
  Elemente verschieben und sogar Logik hinzufügen,
• 2:10
  für die man in den nativen SharePoint-Formulareinstellungen viel länger bräucht.
• 2:14
  Diese Illusion von schnellem Fortschritt ist stark.
• 2:16
  Was Sie noch nicht sehen, ist alles, was im Hintergrund abläuft,
• 2:18
  wie eng diese benutzerdefinierte Logik mit SharePoint-Daten verknüpft ist
• 2:21
  und wie anfällig sie wird, sobald man die sichere Umgebung des Vorschau-Modus verlässt.
• 2:25
  Meistens von uns kennen es.
• 2:26
  Sie testen Ihr Formular mit Beispieldaten,
• 2:28
  klicken auf Speichern und sehen zu,
• 2:30
  wie der Datensatz einwandfrei in die Liste übertragen wird.
• 2:32
  Fügen Sie ein paar Geschäftsregeln hinzu,
• 2:33
  wie das automatische Ausfüllen des anfragenden Namens
• 2:35
  oder das Deaktivieren des Senden-Buttons,
• 2:37
  bis alle Pflichtfelder ausgefüllt sind, alles reagiert zu voll sind.
• 2:40
  In diesem Stadium hat man das Gefühl, das Problem gelöst wird.
• 2:43
  Dann erfolgt die Einführung.
• 2:44
  Jemand meldet, dass sein Speichern-Button überhaupt nicht reagiert.
• 2:47
  Eine andere Person bemerkt,
• 2:48
  dass sich das Ladesymbol beim Öffnen des Formulars in Lust dreht.
• 2:50
  Oder Felder verhalten sich je nach Browser unterschiedlich.
• 2:53
  Dasselbe Formular, das bei sorgfältigen Testläufen stabil aussah,
• 2:56
  wirkt nun unvorhersehbar.
• 2:57
  Ich habe diese Lektion auf die harte Tour gelernt,
• 2:59
  als ich ein Anfrageformular für ein internes Team erstellte.
• 3:01
  Bei kontrollierten Tests schien das Formular perfekt.
• 3:03
  Alle Felder waren korrekt ausgerichtet,
• 3:05
  der Übermittlungs-Workflow startete
• 3:06
  und die Oberfläche füllte sich schneller an
• 3:07
  als die Standard-Sharepoint-Erfahrung.
• 3:09
  Doch in der ersten Woche des produktiven Einsatzes
• 3:11
  traten Probleme auf.
• 3:12
  Manche Benutzer konnten die Anfrage gar nicht erst absetzen.
• 3:14
  Bei anderem wurden Daten in der falschen Spalte gespeichert,
• 3:16
  da die Formeln im Hintergrund
• 3:17
  nicht mit der Interpretation bestimmter Feldtyp
• 3:19
  in Sharepoint übereinstimmten.
• 3:20
  Etwas so Einfaches wie eine Ja-Slash-Nein-Spalte,
• 3:23
  die in Power-Apps als
• 3:24
  wahr-Slash-Falschwert behandelt wurde,
• 3:26
  verhielt sich anders,
• 3:26
  sobald Benutzer direkt über Sharepoint damit interagierten.
• 3:29
  Diese Diskrepanz verursachte
• 3:30
  subtile, aber schädliche Probleme.
• 3:32
  Ein Teil der Falle besteht darin,
• 3:34
  anzunehmen, dass das, was man in der Vorschau sieht,
• 3:35
  dem entspricht, was die Benutzer erleben.
• 3:38
  Der Vorschau-Modus ist im Grunde eine Demo-Umgebung.
• 3:39
  Er simuliert weder mehrere Benutzer,
• 3:41
  die gleichzeitig auf das Formular zugreifen,
• 3:43
  noch umfangreiche Listen mit tausenden Datensätzen
• 3:44
  oder Echtzeit-Konflikte mit Hintergrund-Workflows.
• 3:47
  Man testet unter sauberen Bedingungen,
• 3:48
  doch die Produktionsumgebung ist chaotisch.
• 3:50
  Die Leute gehen unterschiedlich mit dem Formular um,
• 3:52
  Sharepoint-Spalten erzwingen Regeln,
• 3:53
  die man nicht bedacht hat,
• 3:54
  und die Logik, die man für wasserdicht hielt,
• 3:56
  bekommt plötzlich Lücken.
• 3:57
  Es ist fast so, als würde man mit einem Spielzeugmodell testen,
• 3:59
  bevor man zur echten Version übergeht.
• 4:01
  Die Risse zeigen sich erst, wenn man skaliert.
• 4:03
  Ein weiterer blinder Fleck ist die Art und Weise,
• 4:05
  wie wir Sharepoint-Spalten mit Power-Apps-Logik erweitern.
• 4:07
  Eine Dropdown-Spalte in Sharepoint mag simpel erscheinen,
• 4:10
  aber sobald man deren Standardverhalten in Power-Apps überschreibt,
• 4:12
  hat man im Wesentlichen einen Teil
• 4:14
  der integrierten Sharepoint-Validierung
• 4:15
  durch eigenen Code ersetzt.
• 4:18
  Dieser Code stimmt nicht immer mit den Dateneinschränkungen überein,
• 4:20
  die in der Liste weiterhin bestehen.
• 4:22
  Das Ergebnis ist eine Duplizierung der Logik.
• 4:24
  Sharepoint versucht, eine Regel durchzusetzen,
• 4:26
  während Power-Apps eine andere anwendet.
• 4:28
  Wenn sich diese überschneiden,
• 4:29
  erhalten Benutzer inkonsistente Meldungen,
• 4:30
  fehlgeschlagene Speicherungen oder Daten,
• 4:32
  die im Formular sauber aussehen,
• 4:33
  aber später Berichte zerstören.
• 4:35
  Die größere Frage hinter all dem ist,
• 4:36
  ob die Komplexität des Wertes ist.
• 4:38
  Manchmal möchte man nur das Erscheinungsbild
• 4:40
  eines Formulars anpassen,
• 4:41
  doch sobald man es in Power-Apps öffnet,
• 4:42
  öffnet man die Tür zu unendlichen Anpassungsmöglichkeiten.
• 4:45
  Jede kleine Verbesserung hat versteckte Konsequenzen
• 4:48
  und je weiter man geht,
• 4:49
  desto schwieriger wird es,
• 4:49
  Kosmetisches von Strukturellem zu unterscheiden.
• 4:52
  Was sich wie eine elegante Abkürzung anfühlte,
• 4:54
  endet oft in einem Formular,
• 4:55
  das ständig gewartet werden muss.
• 4:56
  Die wahre Herausforderung besteht nicht im Erstellen des Prototyps,
• 4:59
  sondern darin, ihn leistungsfähig zu machen,
• 5:00
  wenn sich täglich Dutzende oder Hunderte von Nutzern darauf verlassen.
• 5:03
  Deshalb treten die Probleme oft erst später auf.
• 5:06
  Ein Formular, das unter ihrer Kontrolle großartig aussah,
• 5:08
  beginnt sich zu verlangsamen, Fehler zu produzieren
• 5:10
  oder die Nutzer zu verwirren, denen es eigentlich helfen sollte.
• 5:13
  Denen es eigentlich helfen soll.
• 5:14
  Das führt zur nächsten Falle,
• 5:15
  Leistungs- und Akzeptanzprobleme,
• 5:16
  die sich erst nach dem Rollout zeigen.
• 5:19
  Die Verborgenen fallen nach dem Rollout.
• 5:20
  Ihr Formular hat jeden Test bestanden,
• 5:22
  den sie durchgeführt hat.
• 5:23
  Dann kamen die ersten echten Nutzer,
• 5:24
  klickten auf Senden
• 5:25
  und alles verlangsamte sich bis zum Stillstand.
• 5:27
  Seiten, die früher sofort geladen wurden,
• 5:28
  zeigen jetzt nur noch Ladesymbole.
• 5:30
  Schaltflächen, die sofort reagieren sollten,
• 5:32
  bevor etwas passiert.
• 5:33
  Das Problem ist nicht,
• 5:34
  dass Ihr Formular plötzlich schlechter geworden ist,
• 5:36
  sondern dass Produktionsdaten Schwachstellen offenlegen,
• 5:38
  die Tests niemals zeigen würden.
• 5:39
  Ein paar ausgewählte Formeln und optische Anpassungen
• 5:41
  wirken bei nur einer Handvoll Beispieldaten nicht schwerfällig.
• 5:43
  Fügen Sie hunderte oder tausende Zeilen in dieselbe Liste ein
• 5:46
  und plötzlich fühlt sich das Formal als nahtlose,
• 5:48
  fast unbrauchbar an.
• 5:49
  Der Unterschied liegt im Maßstab.
• 5:51
  Während der Designphase arbeiten Sie mit 10 Datensinn.
• 5:53
  In der Produktion arbeiten die Leute mit hunderten von Anhängen
• 5:55
  oder Listen, die auf tausende anwachsen.
• 5:57
  Genau dort dreht die Latenz auf.
• 5:58
  Jedes Dropdown-Menü,
• 5:59
  das Elemente aus einer verknüpften Liste abrufen,
• 6:01
  muss TITIT einen separaten Aufbruch.
• 6:02
  Jede bedingte Formel, die Felder ein- oder ausblendet,
• 6:05
  läuft in Echtzeit ab,
• 6:05
  jedes Mal, wenn ein Nutzer mit dem Formular interagiert.
• 6:08
  Kleine Verzögerungen, die einzeln kaum auffallen,
• 6:10
  summieren sich zu etwas, das jeder bemerkt.
• 6:13
  Geschäftsanwender erwarten,
• 6:14
  dass ein Formular so reagiert wie in der Web.
• 6:15
  Entwickler streben oft nach Vollständigkeit.
• 6:17
  Lass uns Logik für jede Bedingung hinzufügen.
• 6:19
  Lass uns fünf Variationen derselben Regel erstellen.
• 6:21
  Doch diese Entscheidungen belasten das Backend.
• 6:23
  Eine Geschichte, die besonders heraussteht,
• 6:25
  handelt von einem Anfrageformular,
• 6:26
  das im Test fehlerfrei wirkte.
• 6:27
  Die Logik funktionierte, das Design sah schick aus.
• 6:29
  Im Vorschau-Modus dauerte es weniger als zwei Sekunden,
• 6:31
  bis es vollständig geladen war.
• 6:32
  Die Demo beeindruckte alle.
• 6:34
  Doch als der Rollout begann
• 6:35
  und eine Abteilung mit einer Liste von bereits tausend Anfragen
• 6:37
  es ausprobierte,
• 6:38
  stieg die Ladezeit auf über 15 Sekunden an.
• 6:41
  Das klingt zunächst nicht dramatisch,
• 6:42
  bis man es auf die tägliche Nutzung hochrechnet.
• 6:44
  Eine halbe Minute Wartezeit pro Anfrage
• 6:46
  bedeutete Dutzende verschwendeter Stunden
• 6:47
  für das gesamte Team.
• 6:49
  Und sobald die Verzögerungen zunehmt,
• 6:50
  verlieren die Leute das Vertrauen in das System.
• 6:51
  Sie klicken aus Panik zwei- oder dreimal auf Speichern,
• 6:54
  was zu doppelten Einreichungen und noch mehr Frust führt.
• 6:56
  Formulare mit dynamischer Logik können das noch verschlimmern.
• 6:59
  Nehmen wir an,
• 6:59
  Sie legen Regeln für die bedingte Sichtbarkeit fest.
• 7:02
  Wählt jemand eine Reiseanfrage aus,
• 7:03
  erweitert sich das Formular um Zielfelder.
• 7:06
  Wählen Sie eine Hardware-Anfrage,
• 7:07
  erscheint ein anderer Abschnitt.
• 7:09
  Theoretisch macht dies das Formular
• 7:10
  wesentlich benutzerfreundlicher.
• 7:12
  In der Realität berechnet sich die Logik
• 7:14
  im Hintergrund bei jeder Auswahl oder Änderung neu.
• 7:17
  Dieser Kreislauf wiederholt sich ständig
• 7:18
  und erzeugt Verzögerungen in der Oberfläche.
• 7:21
  Nutzer beschreiben es so,
• 7:22
  dass das Formular hakt oder einfriert.
• 7:23
  Technisch gesehen berechnet das Formular
• 7:26
  in Echtzeit Dutzende von Ausdrücken neu, neu.
• 7:29
  Im Gegensatz zu Apps,
• 7:29
  die speziell zum Zwischenspeichern von Werten
• 7:31
  oder Bündeln von Anfragen gebaut sind,
• 7:32
  optimiert PowerApps nicht automatisch.
• 7:34
  Jeder Teil der von Ihnen geschriebenen Logik
• 7:35
  wird jedes Mal exakt so ausgeführt,
• 7:36
  wie geschrieben wurde.
• 7:37
  Hier erleben unerfahrene Entwickler oft Überraschungen.
• 7:40
  Man nimmt an,
• 7:40
  die Plattform würde im Hintergrund optimieren,
• 7:42
  dass bestimmte Aufrufe zwischengespeichert
• 7:43
  oder in einer einzigen Anfrage zusammengefasst werden.
• 7:46
  Doch PowerApps erledigt das nicht für Sie.
• 7:47
  Es ruft Daten separat ab
• 7:49
  und berechnet Formeln buchstäblich neu.
• 7:50
  Das Ergebnis ist eine App,
• 7:52
  die sich mit einem Dutzend Elementen gut anfühlt,
• 7:54
  aber unter realen Bedingungen drastisch verlangsamt.
• 7:56
  Erfahrene Entwickler verlagern schwere Logik
• 7:58
  oft aus dem Formular heraus
• 7:59
  in Power Automate Flows oder SharePoint-Regeln.
• 8:02
  Genau deshalb,
• 8:03
  um die Last auf der Client-Seite zu reduzieren.
• 8:05
  Der eigentliche Knackpunkt ist nicht,
• 8:06
  dass diese Probleme auftreten,
• 8:07
  sondern dass sie passieren,
• 8:08
  nachdem Ihr Team Zeit investiert,
• 8:09
  sich auf den Workflow eingelassen hat
• 8:11
  und erwartet,
• 8:12
  dass alles einfach funktioniert.
• 8:14
  Für einen Geschäftsanwender
• 8:15
  fühlt sich eine 10-sekündige Verzögerung
• 8:16
  wie ein Defekt an.
• 8:17
  Für einen Entwickler sind 10 Sekunden
• 8:18
  vielleicht nicht dramatisch,
• 8:19
  doch der Zusammenprall
• 8:20
  dieser Erwartungen führt zu Frustration.
• 8:23
  Aus Nutzersicht verschwendet
• 8:24
  ein langsames Formular Zeit.
• 8:26
  Aus Entwicklersicht erscheint
• 8:27
  das Umschreiben von Logik teuer,
• 8:28
  wenn die Funktionalität bereits vorhanden ist.
• 8:30
  Beide Seiten haben recht
• 8:31
  und beide Seiten verstehen sich gegenseitig.
• 8:33
  Die Lektion dahinter ist einfach.
• 8:34
  Designen Sie für die Produktion,
• 8:35
  nicht für Demo-Bedingungen.
• 8:37
  Wenn Ihre Liste regelmäßig
• 8:38
  Tausende von Einträgen hat,
• 8:39
  testen Sie mit Tausend.
• 8:40
  Wenn Ihre Logik mehrere Spalten betrifft,
• 8:42
  messen Sie die Auswirkungen
• 8:43
  auf die Ladezeit bei hoher Skalierung.
• 8:44
  Wenn Ihr Formular
• 8:45
  benutzerfreundliche Funktionen
• 8:47
  wie bedingte Abschnitte benötigt,
• 8:48
  überlegen Sie genau,
• 8:49
  wie viele Regeln Sie direkt
• 8:50
  im Formular stapeln.
• 8:51
  Jede Sekunde zählt
• 8:52
  und jede unnötige Formel
• 8:54
  wird Sie später einholen.
• 8:56
  Gute Architektur bewirkt
• 8:57
  mehr als eine polierte Optik.
• 8:59
  Leistung ist kein kosmetisches Feature.
• 9:01
  Sie ist das Rückgrat,
• 9:01
  das darüber entscheidet,
• 9:02
  ob Ihre Nutzer beim Formular bleiben
• 9:04
  oder es verlassen.
• 9:05
  Und hier zeigt sich
• 9:06
  die nächste Falle, die Validierung.
• 9:08
  Denn selbst wenn Ihr Formular
• 9:09
  irgendwann schnell genug lädt,
• 9:10
  zerstört nichts das Vertrauen
• 9:11
  so sehr wie ein fehlerhafter Speichervorgang
• 9:12
  oder noch schlimmer eine Speicherung
• 9:13
  und die fehlerhafte Daten
• 9:14
  noch schlimmer eine Speicherung.
• 9:14
  Validierungsalbträume,
• 9:17
  die Sie nicht kommen sehen.
• 9:18
  Auf dem Papier
• 9:18
  wirken Validierungsregeln unkompliziert.
• 9:20
  Sie sehen ein Feld und denken,
• 9:21
  wenn das Enddatum
• 9:22
  vor dem Startdatum liegt,
• 9:23
  gibt ein Fehler aus.
• 9:24
  Wie schwer kann es sein?
• 9:25
  Die Herausforderung ist,
• 9:26
  dass diese einfachen Regeln
• 9:27
  nicht mehr wie erwartet funktionieren,
• 9:28
  sobald Sie das Formular
• 9:29
  aus der sauberen Testumgebung
• 9:30
  in ein Live-Szenario übertragen.
• 9:33
  Eine Prüfung,
• 9:33
  die in der Vorschau einwandfrei funktionierte,
• 9:35
  kann in der Produktion was für statt.
• 9:36
  Oder noch schlimmer,
• 9:37
  sie wird zum falschen Zeitpunkt ausgelöst
• 9:38
  und blockiert Benutzer,
• 9:39
  die glauben,
• 9:39
  alles richtig gemacht zu haben.
• 9:41
  Dann fühlt sich das,
• 9:41
  was eigentlich eine saubere
• 9:42
  Sicherheitsmaßnahme sein sollte,
• 9:43
  an als würde das Formular
• 9:44
  selbst gegen Sie arbeiten.
• 9:45
  Nehmen wir das Szenario
• 9:45
  mit Start- und Enddatum.
• 9:47
  Im Labortest geben Sie
• 9:48
  als Startdatum den 1. Mai
• 9:49
  und als Enddatum
• 9:50
  den 30. April ein
• 9:51
  und Ihre Regel schlägt sofort Alarm.
• 9:52
  Perfekt.
• 9:53
  Doch in der Produktion
• 9:54
  gibt jemand die Werte
• 9:55
  in einer anderen Reihenfolge ein
• 9:56
  oder bearbeitet
• 9:56
  einen bestehenden Datensatz,
• 9:57
  bei dem die Fälle
• 9:58
  bereits teilweise ausgefüllt sind.
• 9:59
  Plötzlich wird die Validierung
• 10:00
  erst beim Speichern ausgelöst
• 10:01
  oder bereits bevor der Benutzer
• 10:02
  mit dem Tippen fertig ist.
• 10:04
  Das sorgt für Verwirrung.
• 10:05
  Sie klicken auf Senden,
• 10:06
  sehen eine Fehlermeldung,
• 10:07
  korrigieren den Fehler,
• 10:08
  klicken erneut auf Senden
• 10:09
  und dann zeigt das Formular
• 10:09
  plötzlich eine andere Meldung
• 10:10
  für etwas anderes.
• 10:11
  Diese gehäuften Fehler
• 10:12
  wirken auf den Benutzer willkürlich,
• 10:13
  doch oft liegt es nur daran,
• 10:14
  dass die Regeln
• 10:14
  in einer unerwarteten Reihenfolge
• 10:15
  ausgeführt werden.
• 10:16
  Ein weiteres häufiges Problem
• 10:17
  tritt auf,
• 10:18
  wenn sich Regeln überschneiden.
• 10:19
  Vielleicht haben Sie eine Formel geschrieben,
• 10:20
  um zu prüfen,
• 10:21
  ob Pflichtfelder ausgefüllt sind
• 10:22
  und eine weitere,
• 10:23
  um Beziehungen zwischen Werten
• 10:24
  zu validieren.
• 10:24
  Wenn beide gleichzeitig ausgelöst werden,
• 10:26
  sieht der Benutzer
• 10:27
  möglicherweise zwei Fehlermeldungen
• 10:28
  auf einmal.
• 10:29
  Oder noch schlimmer,
• 10:30
  eine Meldung verdeckt die andere.
• 10:31
  In manchen Fällen
• 10:32
  finden clevere Benutzer schnell heraus,
• 10:34
  dass sie die Power-Apps-Validierung
• 10:35
  komplett umgehen können,
• 10:36
  indem sie Tastenkombinationen
• 10:37
  verwenden,
• 10:38
  außerhalb des Formulars klicken
• 10:39
  oder bei einer anderen Ansicht
• 10:40
  in SharePoint speichern.
• 10:42
  Für sie fühlt es sich an,
• 10:42
  als sei das Formular defekt.
• 10:43
  Für sie als Ersteller
• 10:44
  fühlt es sich an,
• 10:45
  als würden die Regeln,
• 10:45
  in die sie viel Arbeit gesteckt haben,
• 10:46
  nicht beachtet.
• 10:47
  Beide Frustrationen sind berechtigt.
• 10:49
  Was die Komplexität noch erhöht,
• 10:50
  ist SharePoint selbst.
• 10:51
  Power-Apps ersetzen nicht die Art und Weise,
• 10:53
  wie SharePoint Spaltenbeschränkungen
• 10:53
  durchsetzt.
• 10:55
  Wenn eine Spalte in SharePoint
• 10:56
  erforderlich ist,
• 10:56
  wird SharePoint diese Anforderungen
• 10:57
  weiterhin durchsetzen,
• 10:58
  unabhängig von der Logik in Power-Apps.
• 11:00
  Das Risiko besteht dann,
• 11:01
  wenn ihre Validierungsregeln
• 11:02
  nicht mit der Interpretation
• 11:03
  des Feldes durch SharePoint
• 11:04
  übereinstimmen.
• 11:05
  Sie erlauben beispielsweise
• 11:06
  leere Zeichenfolgen in Power-Apps,
• 11:08
  weil sie nur sichtbare Felder prüfen.
• 11:10
  Gleichzeitig verweigert SharePoint
• 11:11
  den gleichen Datensatz,
• 11:12
  weil dessen Spalte
• 11:12
  als erforderlich markiert ist,
• 11:13
  selbst wenn das Feld
• 11:14
  in ihrem benutzerdefinierten
• 11:15
  Formulager nicht angezeigt wurde.
• 11:16
  Das Ergebnis ist eine Sicherheitsmaßnahme,
• 11:18
  wie der Benutzer
• 11:19
  keine aussagekräftige
• 11:19
  Fehlermeldung anzeigt.
• 11:24
  Diese Lücke zwischen Power-Apps-Regeln
• 11:25
  und der Durchsetzung durch SharePoint
• 11:27
  untergräbt das Vertrauen schnell.
• 11:29
  Nö.
• 11:30
  Den Nutzern ist es egal,
• 11:31
  ob der Fehler von ihrer Formel
• 11:32
  oder dem Backend von SharePoint stammt.
• 11:34
  Sie sehen nur,
• 11:34
  dass ein Formular,
• 11:35
  dem sie vertraut haben,
• 11:35
  plötzlich ihre Eingaben ablehnt.
• 11:37
  Es ist, als würde man einen Damm bauen,
• 11:38
  der bei Tests im Garten solider aussieht.
• 11:40
  Aber sobald man ihn in großem Maßstab
• 11:41
  mit Wasser füllt,
• 11:42
  entstehen kleine Lecks
• 11:43
  an unerwarteten Stellen.
• 11:45
  Jedes Leck für sich wirkt überschaubar,
• 11:46
  aber das Muster signalisiert
• 11:47
  dieser Struktur.
• 11:48
  Kann man nicht trauen.
• 11:50
  Sie können sich vorstellen,
• 11:51
  was das für ihr Akzeptanz bedeutet.
• 11:52
  Nach ein paar schlechten Erfahrungen
• 11:53
  hören die Leute entweder ganz auf,
• 11:54
  Daten einzugeben
• 11:55
  oder suchen nach Umwegen,
• 11:56
  um das Formular nicht nutzen zu müssen.
• 11:57
  Dies ist der Punkt,
• 11:58
  an dem Fachleute oft die meiste Zeit
• 11:59
  mit der Fehlerbehebung verbringen.
• 12:01
  Nicht mit Design oder Layout,
• 12:03
  sondern damit herauszufinden,
• 12:04
  warum bestimmte Grenzfälle
• 12:04
  das Formular in unvorhersehbare Zustände versetzen.
• 12:07
  Am Ende testen sie
• 12:08
  20 verschiedene Eingabekombinationen,
• 12:10
  nur um zu verstehen,
• 12:10
  wie die Regeln ausgelöst werden.
• 12:12
  Und je tiefer man einsteigt,
• 12:13
  desto deutlicher wird,
• 12:14
  dass Validierung nicht aus
• 12:15
  ein oder zwei sauberen Formeln besteht.
• 12:17
  Es geht darum,
• 12:17
  Prüfungen so zu schichten,
• 12:18
  dass sie das Nutzerverhalten,
• 12:19
  die Einschränkungen von SharePoint
• 12:20
  und Grenzfälle berücksichtigen,
• 12:22
  die man vor der Einführung
• 12:23
  nicht vorhersehen kann.
• 12:24
  Der stärkste Ansatz ist es,
• 12:26
  die Validierung in Ebenen zu denken.
• 12:27
  Eine Ebene in PowerApps
• 12:28
  für sofortiges Feedback,
• 12:30
  eine weitere in SharePoint
• 12:31
  zur Sicherung der Datenintegrität,
• 12:32
  egal wie der Datensatz gespeichert wird.
• 12:34
  Und dann zusätzliche Tests
• 12:35
  nicht nur mit sauberen Daten,
• 12:36
  sondern mit der chaotischen Realität,
• 12:38
  das Nutzerdatensatz überarbeiten,
• 12:39
  Pflichtfelder überspringen
• 12:40
  oder Daten eingeben,
• 12:41
  die Jahre statt Wochen umspannen.
• 12:43
  Wenn sie ihre Regeln
• 12:44
  mit SharePoint-Einstellungen absichern
• 12:45
  und die PowerApps-Validierung
• 12:47
  als erste statt als einzige
• 12:48
  Verteidigungslinie betrachten,
• 12:49
  schaffen sie Leitplanken
• 12:50
  statt Sprüderbarriere.
• 12:52
  Die wichtigste Erkenntnis ist,
• 12:53
  Validierung scheitert nicht,
• 12:54
  weil die Regeln falsch sind,
• 12:56
  sondern weil sie zwischen PowerApps
• 12:57
  und SharePoint nicht
• 12:57
  aufeinander abgestimmt sind
• 12:58
  oder nur unter perfekten Bedingungen
• 12:59
  getestet wurden.
• 13:01
  Zuverlässigkeit entsteht durch Schichtung
• 13:02
  und die Planung von Fehlern,
• 13:03
  nicht nur durch das Programmieren
• 13:04
  für den Idealfall.
• 13:05
  Und genau hier zeigt sich
• 13:06
  die wachsende Kluft
• 13:07
  bei der Zuverlässigkeit.
• 13:09
  Zwischen nativen SharePoint-Formularen,
• 13:11
  die einfach Regeln durchsetzen
• 13:12
  und angepassten PowerApps-Formularen,
• 13:14
  die sowohl Flexibilität
• 13:15
  als auch Unvorhersehbarkeit
• 13:16
  bewältigen müssen.
• 13:18
  Native-Formulare
• 13:18
  gegenüber PowerApps,
• 13:20
  Stabilität gegenüber Flexibilität.
• 13:22
  Wenn die integrierten SharePoint-Formulare
• 13:23
  die Arbeit direkt erledigen,
• 13:24
  warum sollte man sie überhaupt
• 13:25
  gegen PowerApps austauschen?
• 13:28
  Das ist die Frage,
• 13:28
  der sich die meisten von uns stellen,
• 13:29
  sobald die Begeisterung
• 13:30
  für die Anpassung nachlässt.
• 13:32
  Native SharePoint-Formulare
• 13:33
  mögen schlicht aussehen,
• 13:34
  aber sie gehen fast nie kaputt.
• 13:35
  Sie erhalten eine zuverlässige
• 13:36
  Eingabevalidierung,
• 13:37
  eine konsistente Darstellung
• 13:38
  auf einem Gerät
• 13:38
  und keinen zusätzlichen Wartungsaufwand.
• 13:40
  Der Kompromiss ist,
• 13:40
  dass sie starr sind,
• 13:41
  wenn ein Feld nur unter
• 13:42
  bestimmten Bedingungen erscheinen soll
• 13:43
  oder sie Abschnitte benötigen,
• 13:44
  die sich dynamisch
• 13:45
  an Geschäftsregeln anpassen,
• 13:46
  stoßen sie mit der Standardoption
• 13:47
  an Grenzen, stoßen sie.
• 13:49
  PowerApps verspricht,
• 13:50
  diese Lücke zu schließen,
• 13:51
  indem es ihnen die Kontrolle
• 13:51
  über Logik, Layout
• 13:52
  und Automatisierung gibt,
• 13:53
  wie es SharePoint allein nicht kann.
• 13:55
  Der Kontrast wird sofort deutlich,
• 13:56
  wenn man sie direkt
• 13:57
  miteinander vergleicht.
• 13:58
  Ein standardmäßiges
• 13:59
  SharePoint-Formular
• 13:59
  öffnet sich sofort,
• 14:00
  erfordert keine Konfiguration
• 14:01
  und erzwingt einfache
• 14:02
  Listeneinstellungen.
• 14:03
  Doch das Design ist
• 14:04
  starr vorgegeben.
• 14:04
  Man kann nicht festlegen,
• 14:05
  zeige dieses Feld nur,
• 14:06
  wenn der Anfragende
• 14:07
  ein Manager ist
• 14:12
  genau diese Flexibilität.
• 14:13
  Sie möchten kaskadierende
• 14:14
  Dropdown-Menüs,
• 14:15
  die an eine Nachschlage ist,
• 14:15
  kein Problem.
• 14:17
  Sie möchten Abschnitte,
• 14:17
  die sich nur dann zeigen,
• 14:18
  wenn bestimmte Bedingungen
• 14:19
  erfüllt sind?
• 14:20
  Also nur ein paar Formeln entfernen.
• 14:22
  Das ist zwar bestärkend,
• 14:23
  aber diese Freiheit
• 14:23
  bringt eine Art Instabilität
• 14:25
  mit sich,
• 14:25
  die man erst später bemerkt.
• 14:27
  Hier liegt das Dilemma
• 14:28
  Stabilität oder Flexibilität.
• 14:30
  Sie können einen Weg wählen,
• 14:31
  der langweilig,
• 14:32
  aber konsistent ist
• 14:33
  oder den Weg,
• 14:33
  der genau die Nutzererfahrung bietet,
• 14:35
  die Sie sich vorgestellt haben,
• 14:36
  aber später bei Problemen
• 14:37
  frustrieren könnte.
• 14:40
  Bei einem Projekt
• 14:41
  für ein Antragsformular
• 14:42
  fiel die Wahl auf Flexibilität.
• 14:44
  Das Team wünschte sich
• 14:44
  eine bedingte Sichtbarkeit.
• 14:46
  Bestimmte Anfragetypen
• 14:47
  erforderten zusätzliche
• 14:48
  Informationsbereiche,
• 14:49
  andere wiederum nicht.
• 14:50
  Im nativen SharePoint
• 14:51
  war dies nicht möglich,
• 14:51
  ohne separate Formulare zu erstellen.
• 14:53
  PowerApps schien
• 14:54
  die offensichtliche Lösung zu sein.
• 14:56
  Während der Entwicklung
• 14:56
  und der ersten Demos
• 14:57
  funktionierte das Formular
• 14:58
  hervorragend.
• 14:59
  Bei der Auswahl von Reise
• 15:00
  wurde ein Bereich
• 15:00
  für Flugdetails eingeblendet.
• 15:02
  Bei der Auswahl von Hardware
• 15:03
  wurden diese Felder
• 15:04
  durch Gerätespezifikationen ersetzt.
• 15:05
  Es fühlte sich maßgeschneidert an,
• 15:07
  auf eine Weise,
• 15:07
  die Standardlösungen
• 15:08
  nie bieten können.
• 15:09
  Die Überraschung kam bei der Einführung.
• 15:11
  In Desktop-Browsern
• 15:11
  funktionierte alles reibungslos,
• 15:13
  doch sobald Nutzer versuchten,
• 15:14
  es über Mobilgeräte abzuschicken,
• 15:15
  bröckelte die Fassade.
• 15:16
  Abschnitte verschoben sich,
• 15:17
  Schaltflächen rutschten
• 15:18
  unter dem Bildschirmrand.
• 15:19
  Manche bedingte Logik
• 15:20
  löste je nach mobilem Client
• 15:22
  inkonsistent aus.
• 15:23
  Funktionen,
• 15:24
  die das SharePoint-Standardformular
• 15:25
  problemlos bewältigte,
• 15:26
  wie etwa die konsistente Darstellung
• 15:27
  auf verschiedenen Geräten,
• 15:28
  wurden plötzlich zum Problemfall.
• 15:30
  Um diese Fehler zu beheben,
• 15:31
  mussten wir Teile des Designs überdenken,
• 15:33
  mit mehreren mobilen Apps testen
• 15:34
  und akzeptieren,
• 15:35
  dass einige Nutzer
• 15:39
  das war ein Preis,
• 15:39
  den das Team beim Streben
• 15:40
  nach Flexibilität nicht bedacht hatte.
• 15:42
  Und es erinnert an etwas,
• 15:43
  das man leicht übersieht.
• 15:45
  Stabilität bedeutet nicht nur,
• 15:46
  dass das System nicht abstützt,
• 15:47
  es bedeutet konsistentes Verhalten
• 15:49
  in jedem Szenario,
• 15:50
  dem ihre Nutzer begegnen.
• 15:52
  Der Druck,
• 15:52
  der Menschen zu Power-Apps treibt,
• 15:54
  ist meist die Geschäftslogik.
• 15:55
  Reale Prozesse passen selten
• 15:56
  in ein generisches Formular.
• 15:58
  Dinge wie bedingte Anforderungen,
• 15:59
  vorausgefüllte Standardwerte
• 16:00
  oder mehrstufige Genehmigungen
• 16:02
  drängen sie weg von nativen Formularen.
• 16:03
  Und Workflows,
• 16:04
  die in Power Automate integriert sind,
• 16:05
  funktionieren besser,
• 16:06
  wenn sie durch benutzerdefinierte Felder
• 16:07
  und Regeln ausgelöst werden,
• 16:08
  die sie in Power-Apps festlegen.
• 16:09
  Deshalb tauschen Unternehmen
• 16:10
  ihre Formulare
• 16:11
  trotz der Risiken weiterhin aus.
• 16:14
  Es liegt nicht daran,
• 16:14
  dass Power-Apps schöner aussieht,
• 16:16
  sondern daran,
• 16:16
  dass native Formulare
• 16:17
  oft reale Geschäftsprozesse
• 16:18
  nicht abbilden können,
• 16:19
  ohne sie an die Grenzen
• 16:20
  der Technologie anzupassen.
• 16:22
  Dennoch weisen erfahrene Stimmen
• 16:23
  in der Community
• 16:23
  auf eine Gefahr hin.
• 16:25
  Die Verwendung von Power-Apps
• 16:26
  für kosmetische Änderungen
• 16:27
  wie das Neuanordnen von Feldern
• 16:29
  oder ein saubereres Design
• 16:30
  rechtfertigt den Aufwand selten.
• 16:32
  Kosmetische Anpassungen
• 16:33
  sind der am wenigsten wertvolle
• 16:34
  und riskanteste Grund
• 16:35
  für die Einführung von Power-Apps.
• 16:37
  Wenn es ihnen nur um die Optik geht,
• 16:38
  opfern sie möglicherweise
• 16:39
  die Konsistenz
• 16:40
  für einen kaum dauerhaften Gewinn.
• 16:43
  Ohne einen triftigen Grund,
• 16:44
  der auf Funktionalität basiert,
• 16:45
  kann der Verlust an Zuverlässigkeit
• 16:46
  die Vorteile vollständig überwiegen.
• 16:49
  Und das ist die verborgene Wahl.
• 16:50
  Die Zuverlässigkeit sinkt meist,
• 16:51
  wenn man eine native Lösung ersetzt,
• 16:53
  nur weil Power-Apps verfügbar ist
• 16:54
  und nicht,
• 16:54
  weil es die richtige Wahl ist.
• 16:56
  Sie tauschen ein Formular,
• 16:57
  das einfach funktioniert,
• 16:58
  gegen eines,
• 16:58
  das ihre ständige Aufmerksamkeit erfordert.
• 17:00
  Jedes neue Feld
• 17:01
  birgt das Risiko,
• 17:02
  eine Formel zu beschädigen.
• 17:02
  Jedes Plattform-Update
• 17:04
  erfordert neue Tests.
• 17:05
  Die Kosten fallen nicht sofort an,
• 17:06
  sondern durch langfristige Wartung
• 17:07
  und Benutzerfrustration.
• 17:09
  Der Schlüssel liegt nicht darin,
• 17:10
  Power-Apps komplett zu vermeiden,
• 17:11
  sondern bewusst damit umzugehen.
• 17:12
  Fragen Sie sich,
• 17:13
  ob die Anpassung
• 17:13
  einen Mehrwert bietet,
• 17:14
  den SharePoint
• 17:14
  nicht auf andere Weise liefern kann.
• 17:17
  Wenn ja, lohnt es sich,
• 17:17
  die zusätzliche Komplexität einzuplanen.
• 17:19
  Falls nicht,
• 17:19
  behalten Sie das native Formular.
• 17:21
  Eine hinreichend gute Lösung,
• 17:22
  die stabil ist,
• 17:23
  ist fast immer besser
• 17:23
  als eine clevere,
• 17:24
  die bei alltäglicher Nutzung zusammenbricht.
• 17:26
  Die eigentliche Entscheidung
• 17:27
  ist also nicht einfach SharePoint
• 17:28
  gegen Power-Apps,
• 17:28
  sondern zu wissen,
• 17:29
  wann man auf grundlegende
• 17:30
  Zuverlässigkeit setzt
• 17:31
  und wann man die Risiken
• 17:31
  einer individuellen Lösung eingeht.
• 17:33
  Denn sobald Sie eine
• 17:34
  individuelle Lösung wären,
• 17:35
  nehmen Sie Herausforderungen an,
• 17:36
  die Sie nicht ignorieren können
• 17:37
  und der Erfolg hängt davon ab,
• 17:38
  ob Sie diese vorhergesehen haben.
• 17:39
  Und das führt direkt
• 17:40
  zur größeren Frage.
• 17:41
  Wenn Sie sich für Power-Apps entscheiden,
• 17:43
  welche Strategien verhindern,
• 17:44
  dass Ihr Formular
• 17:45
  mit der Zeit anfällig wird?
• 17:47
  Praktische Strategien
• 17:48
  für beständige Power-Apps-Formulare.
• 17:50
  Wenn Power-Apps-Formulare
• 17:51
  also anfällig sind,
• 17:51
  was braucht es wirklich,
• 17:52
  um eines zu erstellen,
• 17:53
  das Bestand hat?
• 17:54
  Dies ist der Teil,
• 17:54
  den viele Leute überspringen.
• 17:55
  Sie springen direkt
• 17:56
  vom Entwurf zum Rollout
• 17:57
  und denken,
• 17:57
  dass ein paar Fehlerbehebungen
• 17:58
  das Formular stabil halten werden.
• 18:01
  Die Realität ist,
• 18:02
  dass es bei Stabilität
• 18:03
  nicht darum geht,
• 18:03
  einzelne Risse zu flicken,
• 18:04
  sondern das Fundament zu formen,
• 18:05
  bevor Risse überhaupt entstehen.
• 18:07
  Ich habe das auf die harte Tour gelernt
• 18:09
  mit einem Antragsformular,
• 18:10
  das immer langsamer wurde,
• 18:11
  egal wie viele Anpassungen ich vornahm.
• 18:12
  Die Version,
• 18:13
  die ich schließlich Bestand hatte,
• 18:14
  war die,
• 18:14
  die von Anfang an diszipliniert
• 18:15
  aufgebaut wurde,
• 18:16
  anstatt mit cleveren Korrekturen am Ende.
• 18:18
  Die erste Strategie besteht darin,
• 18:19
  die Logik gleich zu halten.
• 18:20
  Jede Formel,
• 18:21
  die Sie in Power-Apps hinzufügen,
• 18:22
  wirkt für sich genommen klein,
• 18:23
  aber sie ist ein weiterer Rechenschritt,
• 18:25
  der in Echtzeit
• 18:25
  auf dem Gerät des Benutzers abläuft.
• 18:27
  Häufen sich diese,
• 18:28
  wird Ihr Formularträger.
• 18:30
  Das Auslagern von Aufgaben
• 18:31
  kann den Unterschied machen,
• 18:32
  ob eine Anwendung stabil läuft
• 18:33
  oder Probleme bereitet.
• 18:34
  Power Automate
• 18:35
  eignet sich besser
• 18:35
  für aufwendigere Vorgänge
• 18:36
  wie das Senden von E-Mails,
• 18:37
  das Erstellen zugehöriger Elemente
• 18:39
  oder das Starten von Workflows.
• 18:40
  Das System kann diese Aufgaben
• 18:41
  im Hintergrund erledigen,
• 18:42
  sodass sich Ihr Power-Apps
• 18:43
  Formular auf Eingabe
• 18:44
  und Darstellung konzentrieren kann.
• 18:45
  Dasselbe gilt für SharePoint selbst.
• 18:47
  Wenn ein Feld
• 18:48
  immer eine gültige
• 18:49
  E-Mail-Adresse enthalten muss,
• 18:50
  lassen Sie SharePoint
• 18:50
  diesen Spalten-Typ erzwingen.
• 18:52
  Vermeiden Sie erst
• 18:53
  Regeln in Power-Apps zu duplizieren,
• 18:54
  es sei denn,
• 18:54
  Sie benötigen sofortiges
• 18:55
  visuelles Feedback.
• 18:56
  Zweitens,
• 18:56
  testen Sie nicht nur
• 18:57
  mit den fünf Datensätzen,
• 18:58
  die Sie für die Entwicklung hinzugefügt haben.
• 19:00
  Erstellen Sie Ihren Testplan
• 19:00
  mit Daten in Produktionsgrößen.
• 19:02
  Wenn Sie Tausende von Zeilen
• 19:03
  in der zugrunde liegenden Liste erwarten,
• 19:05
  laden Sie Tausende während des Tests.
• 19:07
  Formulare,
• 19:07
  die in der Vorschau
• 19:08
  Reaktion schnell wirken,
• 19:09
  können sich ganz anders verhalten,
• 19:10
  wenn Sie auf eine Liste zugreifen,
• 19:11
  die bereits monatelange Anfragen
• 19:12
  oder große Anhänge enthält.
• 19:14
  Der Leistungsabfall
• 19:15
  zeigt sich erst bei hoher Auslastung.
• 19:16
  Wenn Sie ihn vor dem Rollout bemerken,
• 19:18
  ersparen Sie sich
• 19:18
  die frustrierende Rückmeldung
• 19:19
  von Benutzern
• 19:20
  über Verzögerungen im Arbeitsalltag.
• 19:22
  Das erscheint mühsam,
• 19:23
  deckt aber oft frühzeitig Engpässe auf
• 19:25
  und gibt Ihnen Zeit,
• 19:25
  Berechnungen zu vereinfachen
• 19:26
  oder die Anzahl der Steuerelemente
• 19:28
  auf einem Bildschirm zu reduzieren.
• 19:29
  Eine dritte Sicherheitsmaßnahme
• 19:30
  ist die mehrstufige Validierung.
• 19:32
  Power-Apps sollte
• 19:32
  die benutzerfreundliche Validierung übernehmen,
• 19:34
  also Benutzer führen,
• 19:35
  Sofortnachrichten anzeigen
• 19:36
  oder fehlende Felder markieren,
• 19:41
  stellen Sie es sich wie zwei Türen
• 19:42
  vor, die bald abgeschlossen werden müssen
• 19:43
  anstatt neu.
• 19:44
  Sollte die Power-Apps-Validierung
• 19:45
  eine fehlerhafte Eingabe übersehen,
• 19:46
  stellt SharePoint vor dem Speichern
• 19:47
  des Datensatzes
• 19:48
  die Datensatzes,
• 19:48
  die Daten integrierte Zeit.
• 19:50
  Dieser mehrstufige Ansatz
• 19:51
  vermeidet die problematische Lücke,
• 19:52
  in der Power-Apps eine Eingabe akzeptiert,
• 19:54
  SharePoint sie jedoch stillschweigend ablehnt.
• 19:56
  Das bedeutet auch,
• 19:57
  dass Berichte konsistent bleiben,
• 19:58
  da die Datenqualität nicht allein davon abhängt,
• 20:00
  dass Benutzer das Formular
• 20:01
  wie erwartet ausfüllen.
• 20:03
  Viertens, dokumentieren Sie Ihre Formeln fortlaufend.
• 20:05
  Das klingt langweilig,
• 20:06
  aber Ihr zukünftiges Ich
• 20:07
  oder schlimmer noch,
• 20:07
  der Kollege, der das Formular übernimmt,
• 20:09
  wird Stunden damit verschwenden,
• 20:10
  einen Ausdruck zu entschlüsseln,
• 20:11
  der damals offensichtlich schien.
• 20:13
  Schon eine kurze Erklärungszeile
• 20:14
  über komplexen Formeln
• 20:15
  kann später viel Verwirrung vermeiden.
• 20:18
  Das Kommentieren von Code
• 20:19
  ist wenig glamourös,
• 20:20
  aber in Power-Apps ist es wichtig,
• 20:22
  da Formeln innerhalb der Eigenschaft
• 20:23
  einander übergehen.
• 20:24
  Ohne Notizen vergessen Sie,
• 20:25
  warum Sie eine Regel
• 20:26
  auf eine bestimmte Weise geschrieben haben
• 20:27
  und schrecken davor zurück,
• 20:28
  sie anzupassen,
• 20:28
  selbst wenn es notwendig wäre.
• 20:30
  Dokumentation hält Ihr Formular wartbar.
• 20:32
  Widerstehen Sie schließlich dem Drang
• 20:33
  zu einem Big Bang Rollout?
• 20:34
  Führen Sie die Anwendung
• 20:35
  in überschaubaren Phasen ein.
• 20:36
  Stellen Sie das Formular
• 20:37
  zuerst einer Pilotgruppe bereit,
• 20:38
  lassen Sie es unter realen Bedingungen testen
• 20:40
  und hören Sie sich Ihr Feedback genauer.
• 20:41
  Sie decken Randfälle auf,
• 20:43
  entdecken Performance-Probleme
• 20:44
  und verstehen das echte Nutzerverhalten,
• 20:46
  bevor das gesamte Unternehmen
• 20:47
  darauf angewiesen ist.
• 20:49
  Phasenweise Iterationen schafft Vertrauen
• 20:51
  und gibt Ihnen Raum,
• 20:52
  die zugrunde liegende Struktur zu korrigieren,
• 20:53
  ohne den Druck ab dem ersten Tag
• 20:54
  absolute Zuverlässigkeit zu liefern.
• 20:56
  Was all diese Schritte zusammenhält,
• 20:58
  ist Disziplin.
• 20:59
  Man kann der Komplexität
• 21:00
  nicht vollständig entkommen,
• 21:01
  sobald man ein SharePoint-Formular
• 21:02
  und Power Apps-Safne.
• 21:03
  Amen.