Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Power Apps-formulieren voor SharePoint: waarom ze in productie breken en hoe je ze betrouwbaar maakt (AI-nasynchronisatie)

Transcript

Power Apps-formulieren voor SharePoint: waarom ze in productie breken en hoe je ze betrouwbaar maakt (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Klaar voor 10 dagen vol Microsoft 365, Copilot, AI, Azure
0:05
Speaker 2: en de mensen die de toekomst van werk vormgeven. Deze
0:08
Speaker 2: januari is M365 komt terug en pakken we het groter aan.
0:12
Speaker 2: Doe mee voor live sessies, praktijkdemo's en praktische kennis van
0:15
Speaker 2: MVP's en experts van over de hele wereld. Geen algemene presentaties,
0:20
Speaker 2: geen eindeloos jargon. We pakken de echte uitdagingen aan Copilot Studio,
0:25
Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu IT-professional,
0:31
Speaker 2: ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou.
0:35
Speaker 2: Met tien volledige dagen kun je meerdere technologieën verkennen en
0:38
Speaker 2: contact leggen met een wereldwijde community. Kijk live mee en
0:41
Speaker 2: neem praktische inzichten mee terug naar je eigen organisatie. Januari 2027,
0:47
Speaker 2: tien dagen, één Microsoft Community. Registratie is nu geopend. Claim
0:52
Speaker 2: vandaag nog je plek. Dat is m365com.net. Meld je nu
1:00
Speaker 2: aan op m365com.net en we zien je live in januari.
1:04
Speaker 2: Je SharePoint-formulier ziet er geweldig uit in PowerApps, totdat het
1:07
Speaker 2: dat niet meer doet. Plotseling slaat de knop niet meer
1:10
Speaker 2: correct op. De veldvalidatie doet vreemd en de prestaties voelen
1:13
Speaker 2: aan als modder. Dit is de waarheid. PowerApps-formulieren zien er
1:16
Speaker 2: vaak bedriegelijk eenvoudig uit, maar bevatten valkuilen die de meeste
1:19
Speaker 2: professionals overvallen. Vandaag zie je precies waar die valkuilen ontstaan
1:23
Speaker 2: in een realistisch aanvraagformulier en de stapsgewijze technieken om je
1:26
Speaker 2: formulier niet alleen mooi te maken, maar ook betrouwbaar te
1:29
Speaker 2: laten werken. Waarom makkelijke starts veranderen in moeilijke problemen? Je
1:33
Speaker 2: klikt op die kleine knop aanpassen met Power Apps en
1:35
Speaker 2: binnen enkele minuten ziet je SharePoint lijstformulier er compleet anders uit.
1:38
Speaker 2: Plotseling zijn het niet langer alleen vakjes en labels. Het
1:41
Speaker 2: is een gepolijste applicatie met keuzelijsten, schakelaars en een fris
1:44
Speaker 2: nieuw design. Het voelt alsof je in recordtijd een app
1:46
Speaker 2: hebt gebouwd. Dat is het spannende gedeelte. Maar de opwinding
1:49
Speaker 2: vervliegt meestal snel, omdat die snelle successen het vaak niet
1:52
Speaker 2: overleven zodra je formulier live gaat en echte mensen het
1:54
Speaker 2: gaan gebruiken. De reden dat het in het begin zo
1:57
Speaker 2: simpel voelt, is dat Power Apps een visuele aanpak aanmoedigt.
2:00
Speaker 2: Je sleept een besturingselement naar het scherm, stelt een eigenschap
2:03
Speaker 2: in met een formule die bijna op Excel lijkt, En
2:05
Speaker 2: het reageert precies zoals verwacht. Binnen één sessie kun je
2:08
Speaker 2: velden verbergen, dingen verplaatsen en zelfs logica toevoegen die veel
2:11
Speaker 2: langer zou duren in de standaard formulierinstellingen van SharePoint. Die
2:14
Speaker 2: illusie van snelle vooruitgang is sterk. Wat je nog niet ziet,
2:17
Speaker 2: is alles wat er aan de achterkant gebeurt. Hoe nou
2:19
Speaker 2: die aangepaste logica verbonden is met SharePoint-gegevens en hoe kwetsbaar
2:22
Speaker 2: het wordt zodra je de veilige omgeving van de voorbeeldmodus verlaat.
2:25
Speaker 2: De meeste van ons hebben dit wel eens meegemaakt. Je
2:27
Speaker 2: test je formulier met voorbeeldgegevens, klikt op opslaan en ziet
2:30
Speaker 2: hoe het record foutloos in de lijst wordt geplaatst. Voeg
2:32
Speaker 2: een paar bedrijfsregels toe, zoals het automatisch invullen van de
2:35
Speaker 2: naam van de aanvrager of het uitschakelen van een verzendknop
2:37
Speaker 2: totdat alle vereiste velden zijn ingevuld, en alles reageert direct.
2:40
Speaker 2: In dit stadium lijkt het alsof je het probleem hebt opgelost.
2:43
Speaker 2: Dan volgt de uitrol. Iemand meldt dat hun opslagknop niets doet.
2:46
Speaker 2: Een ander merkt op dat het laadico niet stopt wanneer
2:48
Speaker 2: het formulier probeert te laden. Of velden gedragen zich anders,
2:51
Speaker 2: afhankelijk van wiens browser er open staat. Hetzelfde formulier dat
2:54
Speaker 2: tijdens een paar zorgvuldige testrondes stabiel leek, voelt nu onvoorspelbaar aan.
2:57
Speaker 2: Ik heb deze Lee op de harde manier geleerd toen
2:59
Speaker 2: ik een aanvraagformulier voor een intern team bouwde. Tijdens de
3:01
Speaker 2: gecontroleerde tests leek het formulier perfect. Elk veld stond goed,
3:05
Speaker 2: de workflow werd geactiveerd en de interface voelde sneller aan
3:07
Speaker 2: dan de standaard SharePoint ervaring. Maar tijdens de eerste week
3:10
Speaker 2: van gebruik in de praktijk kwamen er problemen naar boven.
3:12
Speaker 2: Sommige gebruikers konden helemaal niets indienen. Bij anderen werden gegevens
3:15
Speaker 2: in de verkeerde kolom opgeslagen... omdat de formules achter de
3:18
Speaker 2: schermen niet overeenkwamen met hoe SharePoint bepaalde veldtypen interpreteert. Iets
3:21
Speaker 2: simpels als een ja-nee kolom die in Power Apps als
3:23
Speaker 2: een waar-onwaar waarde wordt behandeld... gedroeg zich niet hetzelfde zodra
3:26
Speaker 2: gebruikers er rechtstreeks vanuit SharePoint interactie mee hadden. Die mismatch
3:30
Speaker 2: veroorzaakte subtiele maar schadelijke problemen. Een deel van de valkuil
3:33
Speaker 2: is aannemen dat wat je in de preview ziet, is
3:35
Speaker 2: wat je gebruikers zullen ervaren. De preview-modus is in feite
3:39
Speaker 2: een demo-omgeving. Het simuleert niet dat meerdere gebruikers tegelijk hetzelfde
3:42
Speaker 2: formulier gebruiken, grote lijsten met duizenden records of real-time conflicten
3:45
Speaker 2: met achtergrond-workflows. Je test onder schone omstandigheden, maar de productieomgeving
3:50
Speaker 2: is rommelig. Mensen benaderen het formulier anders. Colommen in SharePoint
3:53
Speaker 2: dwingen regels af waar je geen rekening mee hield en
3:55
Speaker 2: de logica die je waterdicht achtte, vertoont plotseling hiëten. Het
3:57
Speaker 2: is bijna alsof je test met een speelgoedmodel voordat je
3:59
Speaker 2: overstapt naar de echte versie. De scheuren verschijnen pas zodra
4:02
Speaker 2: je opschaalt. Een andere blinde vlek is de manier waarop
4:05
Speaker 2: we SharePoint-colommen uitbreiden met PowerApps-logica. Een vervolgkeuzemenu in SharePoint lijkt
4:10
Speaker 2: misschien eenvoudig, Maar zodra je het standaardgedrag in Power Apps overschrijft,
4:13
Speaker 2: heb je in feite een deel van de ingebouwde validatie
4:16
Speaker 2: van SharePoint vervangen door je eigen code. Die code komt
4:18
Speaker 2: niet altijd overeen met de databeperkingen die nog steeds in
4:21
Speaker 2: de lijst bestaan. Het resultaat is een duplicatie van logica.
4:24
Speaker 2: SharePoint probeert de ene regel af te dwingen terwijl Power
4:27
Speaker 2: Apps een andere toepast. Wanneer die overlappen, krijgen gebruikers inconsistente meldingen,
4:30
Speaker 2: mislukte opslagacties of gegevens die in het formulier netjes lijken,
4:33
Speaker 2: maar later rapporten kapotmaken. De grotere vraag die hieronder ligt,
4:37
Speaker 2: is of de complexiteit het wel waard is. Soms hoef
4:39
Speaker 2: je alleen het uiterlijk van een formulier aan te passen,
4:41
Speaker 2: maar zodra je het opent in Power Apps, open je
4:43
Speaker 2: de deur naar eindeloze aanpassingen. Elke kleine verbetering heeft verborgen
4:47
Speaker 2: gevolgen en hoe verder je gaat, hoe moeilijker het wordt
4:50
Speaker 2: om het cosmetische van het structurele te scheiden. Wat voelde
4:53
Speaker 2: als een slimme kortere weg, eindigt vaak als een formulier
4:55
Speaker 2: dat continu onderhoud vereist. De echte uitdaging is niet het
4:58
Speaker 2: prototype bouwen, maar zorgen dat het presteert wanneer tientallen of
5:01
Speaker 2: honderden gebruikers er dagelijks op vertrouwen. Daarom komen de problemen
5:05
Speaker 2: vaak pas later aan het licht. Een formulier dat perfect
5:07
Speaker 2: werkt onder jouw beheer, begint te vertragen, vast te lopen
5:11
Speaker 2: of de gebruikers voor wie het bedoeld was te verwarren.
5:13
Speaker 2: Dit leidt tot de volgende valkuil, prestatie- en acceptatieproblemen die
5:17
Speaker 2: pas na de uitrol zichtbaar worden. De verborgen valkuilen na
5:20
Speaker 2: de uitrol. Jouw formulier doorstond elke test die je uitvoerde,
5:23
Speaker 2: maar toen de eerste echte gebruikers kwamen, op verzenden, klikte,
5:26
Speaker 2: vertraagde alles tot een slakkegang. Pagina's die voorheen direct laden,
5:28
Speaker 2: tonen nu alleen nog maar draaiende iconen. Knoppen die direct
5:31
Speaker 2: zouden moeten reageren, doen er seconden over. Het probleem is
5:34
Speaker 2: niet dat het formulier plotseling slechter is, maar dat productiedata
5:37
Speaker 2: zwakheden blootlegt die tijdens het testen verborgen bleven. Een paar
5:40
Speaker 2: slimme formules en visuele aanpassingen lijken niet zwaar als je
5:42
Speaker 2: slechts een handvol voorbeeldrecords hebt. Voeg honderden of duizenden rijen
5:45
Speaker 2: toe aan diezelfde lijst en ineens voelt wat naadloos aanvoelde
5:48
Speaker 2: bijna onbruikbaar aan. Het verschil zit in de schaal. Tijdens
5:51
Speaker 2: het ontwerp werk je met tien records. In productie werken
5:54
Speaker 2: mensen met honderden bijlagen of lijsten die doorgroeien tot in
5:56
Speaker 2: de duizenden. Dat is waar vertraging optreedt. Elke keuzelijst die
5:59
Speaker 2: items uit een gerelateerde lijst moet ophalen, doet een aparte aanroep.
6:02
Speaker 2: Elke voorwaardelijke formule die velden toont of verbergt, wordt in
6:05
Speaker 2: real-time uitgevoerd zodra een gebruiker het formulier gebruikt. Kleine vertragingen
6:09
Speaker 2: die je individueel niet opmerkt, stapelen zich op tot iets
6:11
Speaker 2: dat iedereen merkt. Zakelijke gebruikers verwachten dat een formulier reageert
6:14
Speaker 2: als een normale webpagina. Ontwikkelaars streven vaak naar volledigheid. Laten
6:17
Speaker 2: we logica toevoegen voor elke voorwaarde. Laten we vijf variaties
6:20
Speaker 2: van dezelfde regel maken. Maar die keuzes zorgen voor extra
6:23
Speaker 2: belasting op de backend. Een opvallend verhaal is dat van
6:25
Speaker 2: een aanvraagformulier dat tijdens het testen foutloos leek. De logica werkte,
6:28
Speaker 2: het ontwerp zag er strak uit. In de voorbeeldmodus duurde
6:30
Speaker 2: het minder dan twee seconden om volledig te laden. De
6:33
Speaker 2: demo maakte indruk op iedereen. Maar bij de uitrol, toen
6:35
Speaker 2: een afdeling met een lijst van al duizend aanvragen het probeerde,
6:38
Speaker 2: liep de laadtijd op tot meer dan vijftien seconden. Dat
6:41
Speaker 2: klinkt niet vreselijk, totdat je het vermenigvuldigt met dagelijks gebruik.
6:44
Speaker 2: Een halve minuut wachten per aanvraag betekende tientallen verloren uren
6:48
Speaker 2: voor het hele team. En zodra vertraging optreedt, verliezen mensen
6:51
Speaker 2: hun vertrouwen in het systeem. Ze klikken in paniek twee
6:53
Speaker 2: of drie keer op opslaan, wat leidt tot dubbele inzendingen
6:56
Speaker 2: en nog meer frustratie. Formulieren met dynamische logica kunnen dit
6:58
Speaker 2: erger maken. Stel dat je regels instelt voor voorwaardelijke zichtbaarheid.
7:02
Speaker 2: Als iemand een reisaanvraag selecteert, wordt het formulier uitgebreid met bestemmingsvelden.
7:06
Speaker 2: Als ze kiezen voor een hardwareaanvraag, verschijnt er een ander gedeelte.
7:09
Speaker 2: In theorie maakt dit het formulier veel gebruiksvriendelijker. In werkelijkheid
7:12
Speaker 2: wordt de logica achter de schermen telkens opnieuw berekend wanneer
7:15
Speaker 2: een gebruiker een veld selecteert of wijzigt. Die cyclus herhaalt
7:18
Speaker 2: zich constant en zorgt voor haperingen in de interface. Gebruikers
7:21
Speaker 2: omschrijven het als een formulier dat vertraagt of vastloopt. De
7:24
Speaker 2: technische waarheid is dat het formulier tientallen expressies in realtime
7:27
Speaker 2: opnieuw berekent. In tegenstelling tot apps die specifiek zijn gebouwd
7:30
Speaker 2: om waarden te cashen of verzoeken te groeperen, optimaliseert Power
7:33
Speaker 2: Apps niet automatisch. Elk stukje logica dat je schrijft, wordt
7:35
Speaker 2: elke keer precies zo uitgevoerd als geschreven. Dit is waar
7:38
Speaker 2: onervaren bouwers voor verrassingen komen te staan. Je gaat ervan
7:40
Speaker 2: uit dat het platform achter de schermen optimaliseert, dat bepaalde
7:43
Speaker 2: aanroepen worden gecachet of gecombineerd tot één verzoek. Maar Power
7:46
Speaker 2: Apps doet dat niet voor je. Het haalt gegevens afzonderlijk
7:49
Speaker 2: op en herberekenen formules letterlijk. Het resultaat is een app
7:52
Speaker 2: die prima werkt met een dozijn items, maar dramatisch vertraagt
7:55
Speaker 2: op werkelijke schaal. Ervaren ontwikkelaars verplaatsen zware logica vaak buiten
7:59
Speaker 2: het formulier naar power, automate, stromen of sharepoint regels. Juist
8:03
Speaker 2: om de belasting aan de clientzijde te verminderen. Het echte
8:05
Speaker 2: knelpunt is niet dat deze problemen voorkomen, maar dat ze
8:08
Speaker 2: gebeuren nadat je teamtijd heeft geïnvesteerd, in de workflow is
8:11
Speaker 2: gaan geloven en verwacht dat alles gewoon werkt. Voor een
8:14
Speaker 2: zakelijke gebruiker voelt een vertraging van 10 seconden als defect.
8:17
Speaker 2: Voor een ontwikkelaar voelt 10 seconden misschien niet dramatisch, maar
8:20
Speaker 2: de botsing tussen die verwachtingen zorgt voor frustratie. Vanuit het
8:23
Speaker 2: perspectief van de gebruiker is een traag formulier tijdverspilling. Vanuit
8:26
Speaker 2: het perspectief van de ontwikkelaar voelt het herschrijven van logica
8:28
Speaker 2: duur aan wanneer de functionaliteit er al is. Beide partijen
8:31
Speaker 2: hebben gelijk en beide partijen begrijpen elkaar niet. De lay
8:33
Speaker 2: hier is simpel, ontwerp met productie in gedachten, niet voor demo-omstandigheden.
8:37
Speaker 2: Als je lijst regelmatig duizenden items zal bevatten, test dan
8:40
Speaker 2: ook met duizenden. Als je logica meerdere kolommen raakt, meet
8:43
Speaker 2: dan wat dit doet met de laadtijd op schaal. Als
8:45
Speaker 2: je formulier gebruiksvriendelijke functies nodig heeft, zoals voor waardelijke secties,
8:48
Speaker 2: denk dan goed na over hoeveel regels je direct in
8:50
Speaker 2: het formulier stapelt. Elke seconde telt en elke onnodige formule
8:54
Speaker 2: zal je later achtervolgen. Een goede architectuur maakt meer verschil
8:57
Speaker 2: dan gepolijste visuals. Prestaties zijn geen cosmetische functie, het is
9:01
Speaker 2: de echte ruggengraad die bepaalt of je gebruikers bij het
9:03
Speaker 2: formulier blijven of het verlaten. En daar komt de volgende
9:06
Speaker 2: valstrik naar voren, validatie. Want zelfs als je formulier uiteindelijk
9:09
Speaker 2: snel genoeg laat, is er niets dat het vertrouwen zo
9:11
Speaker 2: schaadt als een opslag die mislukt, of erger nog, een
9:13
Speaker 2: opslag die stilletjes foute gegevens accepteert. Validatie-nachtmerries die je niet
9:17
Speaker 2: ziet aankomen. Op papier lijken validatieregels eenvoudig. Je kijkt naar
9:20
Speaker 2: een veld en denkt als de einddatum voor de begindatum valt,
9:23
Speaker 2: geef dan een foutmelding. Hoe moeilijk kan dat zijn? De
9:25
Speaker 2: uitdaging is dat zodra je het formulier uit je schone
9:28
Speaker 2: testomgeving in een live scenario plaatst, die eenvoudige regels zich
9:31
Speaker 2: anders gaan gedragen dan verwacht. Een controle die prima werkt
9:34
Speaker 2: in de preview, kan geruisloos falen in productie. Of erger nog,
9:37
Speaker 2: hij wordt op het verkeerde moment geactiveerd en blokkeert gebruikers
9:39
Speaker 2: die denken dat ze alles correct hebben ingevuld. Op dat
9:41
Speaker 2: moment voelt wat een betrouwbare beveiliging zou moeten zijn, alsof
9:43
Speaker 2: het formulier zelf tegen je werkt. Neem dat scenario met
9:46
Speaker 2: de begin- en einddatum. In een labtest voer je een
9:48
Speaker 2: begindatum van 1 mei in en een einddatum van 30
9:50
Speaker 2: april en je regelmarkeert dit direct. Perfect. Maar in productie
9:54
Speaker 2: voert iemand de waarden in een andere volgorde in of
9:56
Speaker 2: bewerkt een bestaand record waarbij de velden al gedeeltelijk zijn ingevuld.
9:59
Speaker 2: Plotseling wordt de validatie pas bij het opslaan geactiveerd of
10:02
Speaker 2: al voordat de gebruiker klaar is met typen. Dit zorgt
10:04
Speaker 2: voor verwarring. Ze klikken op verzenden, zien een foutmelding, herstellen
10:08
Speaker 2: de fout, klikken weer op verzenden en dan geeft het
10:09
Speaker 2: formulier een andere melding voor iets anders. Deze opgestapelde fouten
10:12
Speaker 2: voelen willekeurig voor de gebruiker, maar vaak is het gewoon
10:14
Speaker 2: de volgorde waarin regels worden uitgevoerd. Een ander veel voorkomend
10:17
Speaker 2: probleem doet zich voor wanneer regels elkaar overlappen. Misschien heb
10:19
Speaker 2: je één formule geschreven om te controleren of verplichte velden
10:22
Speaker 2: zijn ingevuld en een andere om de relaties tussen waarden
10:24
Speaker 2: te controleren. Als beide tegelijk worden geactiveerd, ziet de gebruiker
10:27
Speaker 2: mogelijk twee foutbanners tegelijk. Of nog erger, de ene melding
10:31
Speaker 2: verbergt de andere. In sommige gevallen ontdekken slimme gebruikers snel
10:34
Speaker 2: dat ze de Power Apps validatie volledig kunnen omzeilen door
10:36
Speaker 2: sneltoetsen te gebruiken, buiten het formulier te klikken of op
10:39
Speaker 2: te slaan vanuit een andere weergave in SharePoint. Voor hen
10:41
Speaker 2: voelt het alsof het formulier kapot is. Voor jou als
10:44
Speaker 2: bouwer voelt het alsof de regels waar je moeite in
10:46
Speaker 2: hebt gestoken niet worden gerespecteerd. Beide frustraties zijn reëel. Wat
10:49
Speaker 2: de complexiteit nog vergroot, is SharePoint zelf. Power Apps vervangt
10:52
Speaker 2: niet de manier waarop SharePoint kolom restricties afdwingt. Als een
10:55
Speaker 2: kolom in SharePoint verplicht is, zal SharePoint die eis altijd afdwingen,
10:58
Speaker 2: ongeacht de logica in Power Apps. Het risico ontstaat wanneer
11:01
Speaker 2: jouw validatieregels niet overeenkomen met hoe SharePoint hetzelfde veld interpreteert. Bijvoorbeeld,
11:06
Speaker 2: je staat lege tekst toe in Power Apps omdat je
11:08
Speaker 2: alleen controleert op zichtbare velden. Ondertussen weigert SharePoint hetzelfde record
11:12
Speaker 2: te accepteren omdat de kolom als verplicht staat gemarkeerd, zelfs
11:14
Speaker 2: als het veld niet in je aangepaste formulier werd getoond.
11:16
Speaker 2: Het resultaat is een beveiliging die geen duidelijke foutmelding aan
11:19
Speaker 2: de gebruiker toont. Ze zien alleen een draaiend icoontje of
11:22
Speaker 2: een algemene foutmelding dat het opslaan niet is gelukt. Deze
11:25
Speaker 2: kloof tussen PowerApps regels en de handhaving door SharePoint is
11:28
Speaker 2: wat het vertrouwen snel ondermijnt. Gebruikers maakt het niet uit
11:31
Speaker 2: of de fout door jouw formule komt of door de
11:32
Speaker 2: backend van SharePoint. Ze zien alleen dat een formulier waar
11:35
Speaker 2: ze op vertrouwde hun invoer plotseling weigert. Het is alsof
11:38
Speaker 2: je een dam bouwt die in je achtertuin solide lijkt,
11:40
Speaker 2: maar zodra je hem op schaal met water vult, ontstaan
11:43
Speaker 2: er kleine lekken op onverwachte plekken. Elk lek op zich
11:45
Speaker 2: lijkt beheersbaar, maar het patroon geeft een signaal af Deze
11:48
Speaker 2: structuur is onbetrouwbaar. Je kunt je voorstellen wat dat doet
11:51
Speaker 2: met de acceptatie. Na een paar slechte ervaringen stoppen mensen
11:54
Speaker 2: ofwel helemaal met het invoeren van gegevens, of ze bedenken
11:56
Speaker 2: omwegen om het formulier te vermijden. Dit is het punt
11:58
Speaker 2: waarop professionals vaak de meeste tijd kwijt zijn aan probleemoplossing.
12:01
Speaker 2: Niet aan het ontwerp of de layout, maar aan het
12:03
Speaker 2: uitzoeken waarom bepaalde randgevallen het formulier onvoorspelbaar maken. Je eindigt
12:07
Speaker 2: met het testen van twintig verschillende combinaties van invoer om
12:10
Speaker 2: te begrijpen hoe de regels worden getriggerd. En hoe dieper
12:12
Speaker 2: je gaat, hoe meer je ziet dat validatie niet draait
12:15
Speaker 2: om het schrijven van een paar nette formules. Het draait
12:17
Speaker 2: om het aanbrengen van controles die rekening houden met gebruikersgedrag,
12:20
Speaker 2: de beperkingen van SharePoint en randgevallen die je pas kunt
12:22
Speaker 2: voorspellen als het formulier al is uitgerold. De beste aanpak
12:25
Speaker 2: is om validatie-inlagen te bekijken. Een laag in PowerApps voor
12:28
Speaker 2: directe feedback, een andere in SharePoint om gegevensintegriteit af te
12:32
Speaker 2: dwingen ongeacht hoe het record wordt opgeslagen, en daarna extra
12:35
Speaker 2: testen met niet alleen schone invoer, maar ook met de
12:37
Speaker 2: rommelige realiteit van gebruikers die records bewerken, optionele velden overslaan
12:40
Speaker 2: of datums invoeren die jaren in plaats van weken beslaan.
12:43
Speaker 2: Als je je regels ondersteunt met SharePoint-instellingen en PowerApps-validatie ziet
12:47
Speaker 2: als de eerste verdedigingslinie in plaats van de enige, creëer
12:49
Speaker 2: je vangrails in plaats van breekbare barrières. De belangrijkste lee is,
12:53
Speaker 2: validatie faalt niet omdat de regels verkeerd zijn, het faalt
12:55
Speaker 2: omdat ze niet op elkaar zijn afgestemd tussen PowerApps en
12:57
Speaker 2: SharePoint of omdat ze alleen onder perfecte omstandigheden zijn getest.
13:01
Speaker 2: Betrouwbaarheid komt voort uit het aanbrengen van lagen en rekening
13:03
Speaker 2: houden met fouten, niet alleen programmeren voor het ideale scenario.
13:06
Speaker 2: En dit is precies waar we de grotere betrouwbaarheidskloof zien ontstaan.
13:09
Speaker 2: Tussen formulieren die native in SharePoint zijn gebouwd en simpelweg
13:12
Speaker 2: regels afdwingen en aangepaste PowerApps formulieren die jong leren met
13:15
Speaker 2: zowel flexibiliteit als onvoorspelbaarheid. Native formulieren versus PowerApps. Stabiliteit versus flexibiliteit.
13:22
Speaker 2: Als de ingebouwde formulieren van SharePoint de taak standaard aankunnen,
13:25
Speaker 2: waarom zou je ze dan überhaupt vervangen door PowerApps? Dat
13:28
Speaker 2: is de vraag waar de meesten van ons voor staan
13:29
Speaker 2: zodra de opwinding van het aanpassen is weggehebt. Native SharePoint
13:32
Speaker 2: formulieren zien er misschien eenvoudig uit, maar ze gaan bijna
13:34
Speaker 2: nooit kapot. Je krijgt betrouwbare invoervalidatie, consistente weergave op apparaten
13:38
Speaker 2: en nul extra onderhoud. De keerzijde is dat ze rigide zijn.
13:41
Speaker 2: Als je wilt dat een veld alleen onder bepaalde voorwaarden verschijnt,
13:44
Speaker 2: Of als je secties nodig hebt die zich dynamisch aanpassen
13:46
Speaker 2: aan bedrijfsregels, dan volstaat de standaardoptie niet. Power Apps belooft
13:49
Speaker 2: dat gat te dichten door je controle te geven over logica,
13:52
Speaker 2: layout en automatisering op manieren die SharePoint alleen niet kan bieden.
13:55
Speaker 2: Het contrast is duidelijk zodra je ze naast elkaar vergelijkt.
13:58
Speaker 2: Een standaard SharePoint formulier opent direct, vereist geen configuratie en
14:01
Speaker 2: linkt eenvoudige lijstinstellingen af. Maar het ontwerp ligt vast. Je
14:04
Speaker 2: kunt niet zeggen, toon dit veld alleen als de aanvrager
14:07
Speaker 2: een manager is. Of deze velden inklappen wanneer een bepaald
14:10
Speaker 2: antwoord is gekozen. PowerApp springt in de bres en biedt
14:12
Speaker 2: die flexibiliteit wel. Wil je trapsgewijze keuzelijsten gekoppeld aan een opzoeklijst?
14:16
Speaker 2: Geen probleem. Wil je secties die zichzelf pas onthullen als
14:18
Speaker 2: aan bepaalde voorwaarden is voldaan? Dat is een kwestie van
14:21
Speaker 2: een paar formules. Het is versterkend, maar met die vrijheden
14:24
Speaker 2: komt een soort instabiliteit die je pas later opmerkt. Hier
14:27
Speaker 2: ligt het dilemma, stabiliteit of flexibiliteit. Je kunt een pad
14:31
Speaker 2: kiezen dat zij maar consistent is, of de route nemen
14:33
Speaker 2: die precies de gebruikerservaring biedt die je voor ogen had,
14:36
Speaker 2: maar die later kan frustreren als er problemen opduiken. Bij
14:40
Speaker 2: een project voor een aanvraagformulier viel de keuze op flexibiliteit.
14:43
Speaker 2: Het team wilde voorwaardelijke zichtbaarheid. Bepaalde aanvraagtypes hadden een extra
14:47
Speaker 2: informatiepaneel nodig, terwijl anderen dat niet hadden. In standaard SharePoint
14:51
Speaker 2: was dit onmogelijk zonder aparte formulieren te maken. Power Apps
14:54
Speaker 2: leek de voor de hand liggende oplossing. Tijdens de ontwikkeling
14:56
Speaker 2: en eerste demo's werkte het formulier uitstekend. Bij het selecteren
15:00
Speaker 2: van reizen werd een sectie voor vluchtgegevens zichtbaar. Bij het
15:02
Speaker 2: kiezen van hardware werden die velden vervangen door specifieke apparatuurgegevens.
15:05
Speaker 2: Het voelde zo op maat gemaakt voor het proces dat
15:07
Speaker 2: de standaardversie dat nooit had kunnen bieden. De omslag kwam
15:10
Speaker 2: bij de uitrol. Alles werkte soepel in desktop browsers, maar
15:13
Speaker 2: zodra gebruikers probeerden in te dienen vanaf mobiele apparaten, doorbrak
15:16
Speaker 2: dat de illusie. Secties stonden niet goed uitgeleind, knoppen vielen
15:18
Speaker 2: buiten de schermrand. Sommige voorwaardelijke logica werkte inconsistent afhankelijk van
15:22
Speaker 2: de mobiele client. Functies die het standaard SharePoint formulier zonder
15:25
Speaker 2: problemen afhandelde, zoals consistente weergave op verschillende apparaten, werden plotseling pijnpunten.
15:30
Speaker 2: Om deze eigenaardigheden op te lossen, moesten we delen van
15:32
Speaker 2: het ontwerp heroverwegen, testen met meerdere mobiele apps en accepteren
15:35
Speaker 2: dat sommige gebruikers altijd een minder voorspelbare ervaring zouden hebben.
15:38
Speaker 2: Dat was een prijs waar het team geen rekening mee
15:40
Speaker 2: had gehouden bij het najagen van flexibiliteit. En het is
15:42
Speaker 2: een herinnering aan iets dat makkelijk over het hoofd wordt gezien.
15:45
Speaker 2: Stabiliteit betekent niet alleen dat het niet crash. Het betekent
15:48
Speaker 2: consistent gedrag in elk scenario waar je gebruikers mee te
15:51
Speaker 2: maken krijgen. De druk die mensen naar Power Apps drijft,
15:54
Speaker 2: is meestal bedrijfslogica. Echte processen passen zelden in één algemeen formulier.
15:58
Speaker 2: Zaken als voorwaardelijke verrijste, vooraf ingevulde standaardwaarden of goedkeringen in
16:01
Speaker 2: meerdere stappen duwen je allemaal weg van de standaardformulieren. En
16:04
Speaker 2: workflows die zijn geïntegreerd met Power Automate werken beter wanneer
16:06
Speaker 2: ze worden geactiveerd door aangepaste velden en regels die je
16:08
Speaker 2: in Power Apps definieert. Dat is de reden waarom organisaties,
16:11
Speaker 2: ondanks de risico's, hun formulieren blijven vervangen. Dat is niet
16:14
Speaker 2: omdat Power Apps er mooier uitziet, maar omdat standaardformulieren vaak
16:17
Speaker 2: geen echte bedrijfsprocessen aankunnen zonder ze aan te passen aan
16:20
Speaker 2: de beperkingen van de techniek. Toch wijzen ervaren stemmen in
16:23
Speaker 2: de community hierop een gevaar. Power Apps gebruiken voor cosmetische veranderingen,
16:27
Speaker 2: zoals het verplaatsen van velden of het schoner maken van
16:29
Speaker 2: een formulier, is de afweging zelden waard. Cosmetische aanpassingen zijn
16:33
Speaker 2: de minst waardevolle en de meest risicovolle reden om Power
16:36
Speaker 2: Apps te adopteren. Als je business case enkel is om
16:38
Speaker 2: het uiterlijk te verbeteren, offer je wellicht consistentie op voor
16:41
Speaker 2: heel weinig blijvend resultaat. Zonder een sterke reden gebaseerd op functionaliteit...
16:45
Speaker 2: kan het verlies aan betrouwbaarheid de voordelen volledig overstijgen. En
16:48
Speaker 2: dat is de verborgen waarheid. De betrouwbaarheid daalt meestal wanneer
16:51
Speaker 2: je een standaardoplossing vervangt... enkel omdat Power Apps beschikbaar is
16:54
Speaker 2: en niet omdat het de juiste keuze is. Je ruilt
16:56
Speaker 2: een formulier dat gewoon werkt in voor een formulier dat
16:58
Speaker 2: voortdurend je aandacht vereist. Elk nieuw veld vormt een risico
17:01
Speaker 2: dat een formule kapot gaat. Elke platform-update vereist opnieuw testen.
17:05
Speaker 2: De kosten zitten niet in de opstart, maar in langdurig
17:07
Speaker 2: onderhoud en frustratie bij gebruikers... De sleutel is niet om
17:09
Speaker 2: PowerApps volledig te vermijden, maar om doelgericht te blijven. Vraag
17:12
Speaker 2: jezelf af of de aanpassing waarde levert die SharePoint op
17:15
Speaker 2: geen enkele andere manier kan bieden. Als dat zo is,
17:17
Speaker 2: is de extra complexiteit het waard om in te plannen.
17:19
Speaker 2: Zo niet, hou dan het standaardformulier aan. Een voldoende goede
17:22
Speaker 2: oplossing die stabiel is, wint het bijna altijd van een
17:24
Speaker 2: slimme oplossing die bezwijkt onder dagelijks gebruik. De echte beslissing
17:27
Speaker 2: is dus niet simpelweg SharePoint versus PowerApps, maar weten wanneer
17:30
Speaker 2: je kiest voor basisbetrouwbaarheid en wanneer je de risico's van
17:32
Speaker 2: maatwerk accepteert. Want zodra je voor maatwerk kiest, ga je
17:35
Speaker 2: uitdagingen aan die je niet kunt negeren, en succes hangt
17:38
Speaker 2: af van of je die hebt voorzien. En dat leidt
17:40
Speaker 2: direct naar de grotere vraag. Als je besluit power apps
17:42
Speaker 2: te gebruiken, welke strategieën voorkomen dan dat je formulier na
17:45
Speaker 2: verloop van tijd fragiel wordt? Praktische strategieën voor duurzame power
17:49
Speaker 2: apps formulieren. Dus, als power apps formulieren fragiel zijn, wat
17:52
Speaker 2: is er dan echt nodig om er een te bouwen
17:53
Speaker 2: die blijft werken? Dit is het onderdeel dat veel mensen overslaan.
17:56
Speaker 2: Ze springen direct van ontwerp naar uithol in de veronderstelling
17:58
Speaker 2: dat een paar bakfixes het formulier stabiel houden. De realiteit
18:02
Speaker 2: is dat stabiliteit niet gaat over het dichten van individuele scheuren,
18:05
Speaker 2: maar over het vormen van het fundament voordat de scheuren ontstaan.
18:07
Speaker 2: Ik heb dit op de harde manier geleerd met een
18:09
Speaker 2: aanvraagformulier dat steeds trager werd, ongeacht hoeveel aanpassingen ik deed.
18:12
Speaker 2: De versie die uiteindelijk stand hield, was degene die vanaf
18:15
Speaker 2: het begin met discipline was opgebouwd in plaats van met
18:17
Speaker 2: slimme fixes achteraf. De eerste strategie is om de logica
18:20
Speaker 2: licht te houden. Elke formule die je toevoegt in PowerApps
18:22
Speaker 2: lijkt op zichzelf klein, maar het is een extra verwerking
18:25
Speaker 2: die in realtime op het apparaat van de gebruiker draait.
18:27
Speaker 2: Stapel er daar genoeg van op en je formulier wordt traag.
18:30
Speaker 2: Taken uitbesteden kan het verschil maken tussen iets dat blijft
18:32
Speaker 2: werken en iets dat in elkaar stort. Power Automate is
18:35
Speaker 2: geschikt voor zwaardere operaties zoals het versturen van e-mails, het
18:38
Speaker 2: aanmaken van gerelateerde items of het starten van workflows. Het
18:40
Speaker 2: systeem kan die taken op de achtergrond afhandelen, waardoor je
18:43
Speaker 2: Power Apps formulier zich kan concentreren op invoer en presentatie.
18:45
Speaker 2: Hetzelfde geldt voor SharePoint zelf. Als een veld altijd een
18:48
Speaker 2: geldig e-mailadres moet bevatten, laat SharePoint dat dan afdwingen via
18:51
Speaker 2: het kolom typen. Vermijd het dupliceren van regels in Power Apps,
18:54
Speaker 2: tenzij je directe visuele feedback nodig hebt. Ten tweede, test
18:57
Speaker 2: niet alleen met de vijf records die je voor ontwikkeling
18:59
Speaker 2: hebt toegevoegd. Stel je testplan op met data op productieniveau.
19:02
Speaker 2: Als je duizenden rijen in de onderliggende lijst verwacht, laat
19:05
Speaker 2: er dan duizenden tijdens het testen. Formulieren die in de
19:07
Speaker 2: voorbeeldweergave snel lijken, kunnen heel anders reageren wanneer ze gegevens
19:11
Speaker 2: ophalen uit een lijst met maanden aan aanvragen of grote bijlagen.
19:14
Speaker 2: De prestatiedaling zie je pas op schaal en als je
19:16
Speaker 2: dit voor de uithol ontdekt, bespaar je jezelf de pijnlijke
19:19
Speaker 2: feedbackkroonde van gebruikers die vertraging ervaren tijdens hun dagelijkse werk.
19:22
Speaker 2: Dit voelt vervelend, maar het legt vaak sneller knelpunten bloot
19:25
Speaker 2: en geeft je de tijd om berekeningen te vereenvoudigen of
19:27
Speaker 2: het aantal besturingselementen op een scherm te verminderen. Een derde
19:30
Speaker 2: waarborg is gelaagde validatie. Power apps moeten gebruiksvriendelijke kant van
19:33
Speaker 2: validatie afhandelen, gebruikers begeleiden, directe meldingen tonen en ontbrekende velden markeren,
19:38
Speaker 2: maar de eigen beperkingen van SharePoint moeten die regels ondersteunen.
19:41
Speaker 2: Zie het als twee deuren die op slot moeten in
19:43
Speaker 2: plaats van één. Als de validatie in Power Apps een
19:45
Speaker 2: foutieve invoer niet opvangt, blinkt SharePoint alsnog de integriteit af
19:48
Speaker 2: voordat het record wordt opgeslagen. Deze gelaagde aanpak voorkomt die
19:51
Speaker 2: vervelende situatie waarin Power Apps zegt dat alles goed is,
19:54
Speaker 2: maar SharePoint het stilzwijgend afwijst. Dit betekent ook dat rapportages
19:57
Speaker 2: consistent blijven, omdat je datakwaliteit niet alleen afhangt van gebruikers
20:01
Speaker 2: die het formulier invullen zoals jij verwachtte. Ten vierde, documenteer
20:04
Speaker 2: je formules terwijl je werkt. Dit klinkt saai, maar je
20:06
Speaker 2: toekomstige zelf, of erger nog, de collega die het formulier overneemt,
20:09
Speaker 2: zal uren verspillen aan het ontrafelen van een expressie die
20:12
Speaker 2: op dat moment voor de hand liggend leek. Zelfs een
20:14
Speaker 2: korte regel uitleg boven complexe formules kan later veel verwarring voorkomen.
20:18
Speaker 2: Code van commentaar voorzien is niet glamoureus, maar in powerapps
20:21
Speaker 2: is het extra belangrijk omdat formules in eigenschappen vaak in
20:23
Speaker 2: elkaar overvloeien. Zonder notities vergeet je waarom je een regel
20:26
Speaker 2: op een bepaalde manier hebt geschreven en zul je twijfelen
20:28
Speaker 2: om hem aan te passen, zelfs als dat nodig is.
20:29
Speaker 2: Documentatie houdt je formulier onderhoudbaar. Tot slot, weersta de drang
20:33
Speaker 2: naar een Big Bang uitrol. Rol het uit in beheersbare fase.
20:36
Speaker 2: Zet het formulier eerst uit bij een pilotgroep, laat ze
20:39
Speaker 2: het onder echte omstandigheden gebruiken en luister goed naar hun feedback.
20:42
Speaker 2: Je ontdekt randgevallen, merkt prestatieproblemen op en begrijpt het echte
20:45
Speaker 2: gebruikersgedrag voordat de hele organisatie ervan afhankelijk is. In fase
20:49
Speaker 2: werken bouwt vertrouwen op en geeft je de ruimte om
20:51
Speaker 2: de onderliggende structuur te verbeteren zonder de druk dat iedereen
20:54
Speaker 2: vanaf dag 1 betrouwbaarheid eist. Wat al deze stappen verbindt,
20:58
Speaker 2: is discipline. Je kunt aan complexiteit niet volledig ontsnappen zodra
21:01
Speaker 2: je een SharePoint-formulier opent in PowerApps. Maar je...