Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Moduli Power Apps per SharePoint: perché si rompono in produzione e come renderli affidabili (Doppiaggio IA)

Transcript

Moduli Power Apps per SharePoint: perché si rompono in produzione e come renderli affidabili (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per 10 giorni di Microsoft 365, Copilot, intelligenza artificiale,
0:04
Speaker 2: Azure e le persone che stanno plasmando il futuro del lavoro?
0:07
Speaker 2: A gennaio torna M365 con E ci stiamo espandendo, E
0:11
Speaker 2: ci stiamo espandendo. Unisciti a noi per sessioni live, dimostrazioni pratiche,
0:15
Speaker 2: conoscenze pratiche da parte di MVP ed esperti del settore
0:17
Speaker 2: di tutto il mondo. Nessuna slide generica, nessun termine di
0:20
Speaker 2: modo infinito. Stiamo affrontando le vere sfide. Copilot Studio, agenti
0:24
Speaker 2: di intelligenza artificiale, Fabric, sicurezza, governance e automazione. Che tu
0:30
Speaker 2: sia un professionista IT, uno sviluppatore o un leader aziendale,
0:32
Speaker 2: ci sono sessioni pensate per te. Con 10 giorni interi
0:36
Speaker 2: puoi esplorare più tecnologie e connetterti con una community globale.
0:40
Speaker 2: Guarda la diretta e porta informazioni pratiche alla tua organizzazione.
0:45
Speaker 2: Gennaio 2027, 10 giorni, una community Microsoft. Le registrazioni sono
0:50
Speaker 2: aperte ora. Vai subito a casa tua. Questo è m365. net. it
1:00
Speaker 2: iscriviti ora su m365com. net e ci vediamo dal vivo a
1:04
Speaker 2: gennaio il tuo modulo di SharePoint ha un aspetto fantastico
1:07
Speaker 2: in PowerApps finché non lo è più improvvisamente il pulsante
1:09
Speaker 2: non viene salvato correttamente la comodità dei campi si comporta
1:11
Speaker 2: in modo strano e le prestazioni sembrano quelle di un'impresario
1:14
Speaker 2: ecco la verità i moduli di PowerApps spesso sembrano indannevolmente
1:17
Speaker 2: semplici ma contengono insidie che colgono di sorpresa la maggior
1:19
Speaker 2: parte dei professionisti oggi vedrai esattamente dove emergono queste insidie
1:22
Speaker 2: in un modulo di richiesta del mondo reale le tecniche
1:24
Speaker 2: dettagliate che possono trasformare il tuo modulo da un bel
1:27
Speaker 2: aspetto a un funzionamento effettivamente affidabile perché gli inizi facili
1:31
Speaker 2: si trasformano in problemi difficili. Fai clic su quel piccolo
1:34
Speaker 2: pulsante Personalizza con Power Apps e in pochi minuti il
1:36
Speaker 2: tuo modulo elenco di SharePoint sembrerà trasformato. Improvvisamente non è
1:40
Speaker 2: più solo case ed etiche. È un'applicazione raffinata come una discesa,
1:42
Speaker 2: interruttori e un tocco di design innovativo. Sembra di aver
1:45
Speaker 2: creato un'app in tempi record. Questa è la parte entusiasmante.
1:48
Speaker 2: Ma l'entusiasmo di solito svanisce rapidamente perché quelle vittorie facili
1:51
Speaker 2: non sempre sopravvivono al momento in cui il tuo modulo
1:53
Speaker 2: viene pubblicato e le persone reali iniziano a utilizzarlo. Il
1:55
Speaker 2: motivo per cui all'inizio sembra così semplice è che Power
1:57
Speaker 2: Apps incoraggia un approccio visivo Trascini un controllo sullo schermo
2:02
Speaker 2: e imposti una proprietà con una formula che assomiglia quasi
2:04
Speaker 2: a Excel e risponde esattamente come previsto. In una singola
2:07
Speaker 2: sessione puoi nascondere campi, spostare elementi e persino aggiungere logica
2:10
Speaker 2: che richiederebbe molto più tempo nelle impostazioni del modulo nativo
2:12
Speaker 2: di SharePoint. Questa illusione di progresso rapido e forte. Ciò
2:16
Speaker 2: che non vedi ancora è tutto ciò che accade al
2:17
Speaker 2: di sotto. Quanto strettamente quella logica personalizzata sia legata ai
2:21
Speaker 2: dati di SharePoint e quanto diventi fragile una volta che
2:23
Speaker 2: esci dall'ambiente sicuro della modalità di anteprima? La maggior parte
2:26
Speaker 2: di noi c'è passato. Testi il tuo modulo con dati
2:28
Speaker 2: di esempio, fai clic su Salva e osservi che inserisce
2:30
Speaker 2: il record nell'elenco senza problemi. Aggiungi alcune regole aziendali, come
2:33
Speaker 2: la compilazione automatica del nome del richiedente o la disabilitazione
2:36
Speaker 2: di un pulsante di invio finché tutti i campi obbligatori
2:38
Speaker 2: non sono compilati e non sono compilate e non sono compilate.
2:40
Speaker 2: A questo punto sembra di aver risolto il problema. Poi
2:43
Speaker 2: avviene il rollout, qualcuno segnala che il pulsante salva non
2:46
Speaker 2: fa nulla, un'altra persona nota che la rotellina non si
2:48
Speaker 2: ferma mai quando il modulo tenta di caricare. Oppure i
2:51
Speaker 2: campi si comportano in modo diverso a seconda del browser aperto.
2:53
Speaker 2: Lo stesso modulo che sembrava stabile durante alcuni test accurati
2:55
Speaker 2: ora sembra imprevedibile. Ho imparato questa lezione a mie spese
2:59
Speaker 2: creando un modulo di richiesta per un team interno. Nei
3:01
Speaker 2: test di controllo il modulo sembrava perfetto. Ogni campo era allineato,
3:04
Speaker 2: il flusso di lavoro di invio si è attivato e
3:06
Speaker 2: l'interfaccia sembrava più veloce rispetto all'esperienza di SharePoint originale. Tuttavia,
3:10
Speaker 2: durante la prima settimana di utilizzo in produzione sono emersi
3:12
Speaker 2: alcuni utenti non riuscivano a inviare nulla. Altri avevano i
3:15
Speaker 2: dati salvati nella colonna sbagliata perché le formule in background
3:17
Speaker 2: non corrispondevano al modo in cui SharePoint interpreta determinati tipi
3:19
Speaker 2: di campo. Qualcosa di semplice come una colonna sino gestita
3:23
Speaker 2: in Power Apps come un valore pubblico. Il vero falso
3:25
Speaker 2: non si comportava allo stesso modo quando gli utenti interagivano
3:27
Speaker 2: con essa direttamente da SharePoint. Tale mancata corrispondenza causava problemi
3:31
Speaker 2: sottili ma dannosi. Parte della trappola è presumere che ciò
3:34
Speaker 2: che vedi nell'anteprima sia ciò che sperimenteranno i tuoi utenti.
3:37
Speaker 2: La modalità di anteprima è essenzialmente un ambiente dimostrativo. Non
3:40
Speaker 2: simula più utenti che accedono allo stesso modulo un elenco
3:42
Speaker 2: di grandi dimensioni con migliaia di record o conflitti in
3:45
Speaker 2: tempo reale con flussi di lavoro in background. Esegui i
3:47
Speaker 2: test in condizioni pulite, ma l'ambiente di produzione è caotico.
3:50
Speaker 2: Le persone affrontano il modulo in modo diverso e le
3:52
Speaker 2: colonne in SharePoint applicano regole di cui non avevi tenuto
3:54
Speaker 2: conto e la logica che pensavi fosse infallibile all'improvviso apre
3:57
Speaker 2: delle lacune. È quasi come testare con un modello giocattolo
3:59
Speaker 2: prima di passare a una versione successiva. Le crepe compaiono
4:01
Speaker 2: solo quando si passa a una versione più grande. Un
4:03
Speaker 2: altro punto cieco è il modo in cui estendiamo le
4:05
Speaker 2: colonne di SharePoint con la logica di PowerApps. Una colonna
4:08
Speaker 2: discesa in SharePoint potrebbe sembrare semplice, ma una volta che
4:11
Speaker 2: ne sostituisci il comportamento predefinito in PowerApps, hai sostanzialmente sostituito
4:14
Speaker 2: parte della convalida incorporata di SharePoint con il tuo codice.
4:18
Speaker 2: Tale codice non è sempre allineato con le restrizioni sui
4:20
Speaker 2: dati ancora presenti nell'elenco. Il risultato è la duplicazione della logica.
4:24
Speaker 2: SharePoint tenta di applicare una regola mentre PowerApps ne applica un'altra.
4:28
Speaker 2: Quando queste si sovrappongono, gli utenti ricevono messaggi incoerenti, salvataggi
4:31
Speaker 2: non riusciti o dati che sembrano puliti nel modulo ma
4:33
Speaker 2: interrompono i report in un secondo momento. La domanda più
4:35
Speaker 2: importante alla base di tutto ciò è se la complessità
4:37
Speaker 2: ne valga la pena. A volte è sufficiente modificare l'aspetto
4:40
Speaker 2: di un modulo, ma una volta aperto in PowerApps si
4:42
Speaker 2: apre la porta a infinite personalizzazioni. Ogni piccolo miglioramento comporta
4:47
Speaker 2: delle conseguenze nascoste e più si va avanti più diventa
4:49
Speaker 2: difficile distinguere ciò che è estinguere e ciò che è strutturale.
4:53
Speaker 2: Ciò che sembrava una scocciatoia facile spesso si trasforma in
4:55
Speaker 2: un modulo che necessita di una manutenzione costante. La verità
4:57
Speaker 2: è che la vera sfida non è creare il prototipo
4:59
Speaker 2: ma far sì che quel prototipo funzioni quando decine o
5:01
Speaker 2: centinaia di utenti vi fanno affidamento ogni giorno. Ecco perché
5:04
Speaker 2: i problemi spesso non si manifestano fino a un momento successivo.
5:06
Speaker 2: Un modulo che sembra perfetto sotto il tuo controllo inizia
5:08
Speaker 2: a rallentare, a inciampare su se stesso o a confondere
5:11
Speaker 2: proprio gli utenti che avrebbe dovuto aiutare, il che porta
5:13
Speaker 2: alla trappola successiva. Problemi di prestazioni e adozione che si
5:16
Speaker 2: rivelano solo dopo l'inizio del lancio. Le trappole nascoste dopo
5:20
Speaker 2: il lancio. Il tuo modulo ha superato tutti i test
5:22
Speaker 2: che gli hai sottoposto. Poi sono arrivati i primi veri
5:24
Speaker 2: utenti e hanno cliccato su inviare, tutto rallentato a dismisura.
5:27
Speaker 2: Le pagine che una volta si caricavano all'istante ora sono
5:29
Speaker 2: lì con delle icone che girano. I pulsanti che dovrebbero
5:31
Speaker 2: attivarsi subito impiegano secondi prima di rispondere. Il problema non
5:34
Speaker 2: è che il tuo modulo è improvvisamente peggiorato, è che
5:36
Speaker 2: i dati di produzione espongono debolezze che i test non
5:38
Speaker 2: rivelano mai. Alcune formule scelte e modifiche visive non sembrano
5:41
Speaker 2: pesanti quando hai solo una lanciata di record campione. Aggiungi
5:44
Speaker 2: centinaia o migliaia di righe nello stesso elenco e improvvisamente
5:47
Speaker 2: ciò che sembrava fluido inizia a sembrare quasi inutilizzabile. La
5:50
Speaker 2: differenza sta nella scala. Durante la progettazione lavori con 10 record.
5:53
Speaker 2: In produzione le persone lavorano con centinaia di allegati o
5:55
Speaker 2: elenchi che aumentano fino a migliaia. È qui che si
5:57
Speaker 2: verifica la latenza. Ogni meno a discesa che dovrai estrarre
6:00
Speaker 2: elementi da un elenco correlato effettua una chiamata separata Ogni
6:03
Speaker 2: formula condizionale che mostra o nasconde i campi viene eseguita
6:05
Speaker 2: in tempo reale ogni volta che un utente interagisce con
6:07
Speaker 2: il modulo. Piccoli costi che non noti singolarmente si trasformano
6:10
Speaker 2: in qualcosa che tutti notano. Gli utenti aziendali si aspettano
6:14
Speaker 2: che un modulo risponda come una pagina. Gli sviluppatori spesso
6:16
Speaker 2: inseguono la completezza. Aggiungiamo logica per ogni condizione. Realizziamo cinque
6:20
Speaker 2: varianti della stessa regola. Ma quelle scelte giungono a carico
6:22
Speaker 2: il backend. Una storia che spicca proviene da un modulo
6:25
Speaker 2: di richiesta che è apparso impeccabile durante i test. La
6:27
Speaker 2: logica ha funzionato, il design era nitido. In modalità anteprima
6:30
Speaker 2: ci sono voluti meno di due secondi per caricarsi completamente.
6:32
Speaker 2: La demo ha impressionato tutto. Ma quando è stato lanciato,
6:35
Speaker 2: il reparto con un elenco che conteneva già mille richieste
6:37
Speaker 2: l'ho approvato. Il carico è aumentato a oltre 15 secondi.
6:41
Speaker 2: Non sembra terribile finché non lo si moltiplica per utilizzo quotidiano.
6:44
Speaker 2: Mezzo minuto di attesa per richiesta significava decine di ore
6:47
Speaker 2: sprecate in tutto il team. E una volta che si
6:50
Speaker 2: verifica il ritardo, le persone smettono di fidarsi. Prendono due
6:52
Speaker 2: o tre volte clic su salve in preda al panico,
6:54
Speaker 2: il che porta a invii duplicati e ancora più frustrazione.
6:57
Speaker 2: Modi di ecologica dinamica possono peggiorare la situazione. Supponiamo di
7:00
Speaker 2: impostare delle regole per la visibilità condizionale. Se qualcuno seleziona
7:03
Speaker 2: richiesta di viaggio, il modulo si espande con i campi
7:05
Speaker 2: di destinazione. Se seleziona richiesta hardware, viene visualizzata una sezione diversa.
7:09
Speaker 2: In teoria questo rende il modulo molto più intuitivo. In
7:12
Speaker 2: realtà ogni volta che un utente seleziona o modifica un campo,
7:15
Speaker 2: la logica dietro le quinte esegue un ricalcolo. Quel ciclo
7:17
Speaker 2: si ripete costantemente creando esitazione nell'interfaccia. Gli utenti lo descrivono
7:22
Speaker 2: come un ritardo o blocco del modulo. La verità tecnica
7:25
Speaker 2: è che il modulo ricalcola decine di espressioni in tempo reale.
7:29
Speaker 2: A differenza delle app create appositamente per memorizzare nella cassa
7:31
Speaker 2: valore richieste batch, Power Apps non esegue l'ottimizzazione automaticamente. Ogni
7:34
Speaker 2: parte di logica scritta viene eseguita esattamente come è stata
7:36
Speaker 2: scritta ogni volta. È qui che gli sviluppatori inesperti rimangono sorpresi.
7:40
Speaker 2: Si dà per scontato che la piattaforma ottimizza in background
7:42
Speaker 2: e che determinate chiamate vengano memorizzate nella cassa o combinate
7:44
Speaker 2: in un'unica richiesta. Ma Power Apps non lo fa per te.
7:48
Speaker 2: Recupera i dati separatamente, riformule e reforma. Il risultato è
7:51
Speaker 2: un'app che funziona bene con una decina di elementi ma
7:54
Speaker 2: rallenta notevolmente in scala reale. I sviluppatori esperti spesso spostano
7:58
Speaker 2: la logica pesante all'esterno del modulo nei flussi di Power
8:00
Speaker 2: Automate o nelle regole di SharePoint, proprio per ridurre il
8:03
Speaker 2: peso che si verifica sul lato client. Il vero problema
8:06
Speaker 2: non è che questi problemi si verifichino, ma che si
8:08
Speaker 2: verificano dopo che il team ha investito tempo, ha aderito
8:10
Speaker 2: al flusso di lavoro e si aspetta che tutto funzioni.
8:14
Speaker 2: Per un utente aziendale un ritardo di 10 secondi sembra inutile.
8:17
Speaker 2: Per uno sviluppatore 10 secondi potrebbero non sembrare un problema,
8:20
Speaker 2: ma è lo scontro tra queste aspettative che genera frustrazione.
8:23
Speaker 2: Dal punto di vista dell'utente, un modulo lento fa perdere tempo,
8:26
Speaker 2: Dal punto di vista dello sviluppatore, scrivere logica sembra costoso
8:28
Speaker 2: quando la funzionalità è già presente. Entrambe le parti hanno ragione,
8:31
Speaker 2: ma entrambe le parti si perdono il centro. La lezione
8:33
Speaker 2: nascosta qui è semplice. Progettare pensando alla produzione, non alle
8:36
Speaker 2: condizioni dimostrate. Se il tuo elenco conterrà regolarmente migliaia di elementi,
8:39
Speaker 2: esegui test con migliaia. Se la tua logica tocca più colonne,
8:42
Speaker 2: misura cosa fa per caricare il tempo su larga scala.
8:45
Speaker 2: Se il tuo modulo necessita di funzionalità di facile utilizzo,
8:47
Speaker 2: come le sezioni condizionali, pensa attentamente a quante regole impili
8:50
Speaker 2: direttamente nel modulo. Ogni secondo conta e ogni formula non
8:53
Speaker 2: necessaria tornerà a perseguitarti in seguito. Una buona architettura fa
8:57
Speaker 2: più differenza di una grafica curata. Le prestazioni non sono
9:00
Speaker 2: una caratteristica estetica, sono la vera spina dorsale che determina
9:03
Speaker 2: se i tuoi utenti resteranno con il modulo o lo abbandoneranno.
9:05
Speaker 2: Ed è qui che si manifesta la trappola successiva, la convalida.
9:08
Speaker 2: Perché anche se il tuo modulo alla fine si carica
9:09
Speaker 2: abbastanza velocemente, niente rovinerà la fiducia con un salvataggio che
9:12
Speaker 2: non riesce o, peggio, con un salvataggio che accetta silenziosamente
9:14
Speaker 2: da terra. Incubi di convalida che non vedi arrivare. Sulla
9:18
Speaker 2: carta le regole di convalida sembrano semplici. Guardi un campo
9:21
Speaker 2: e pensi, se la data di fine precede quella di inizio,
9:23
Speaker 2: genera un errore. Quanto può essere difficile? La sfida è
9:26
Speaker 2: che una volta che hai effettivamente distribuito il modulo dal
9:28
Speaker 2: tuo ambiente di test pulito a uno scenario live, quelle
9:30
Speaker 2: semplici regole smettono di comportarsi come previsto. Un controllo che
9:33
Speaker 2: ha funzionato bene in anteprima può fallire silenziosamente plus. O peggio,
9:37
Speaker 2: viene attivato nel momento sbagliato e blocca gli utenti che
9:39
Speaker 2: pensano di aver fatto tutto correttamente. È in questo caso
9:41
Speaker 2: che quella che dovrebbe essere una salvaguardia pulita sembra essere
9:44
Speaker 2: il modulo stesso che lavora contro te. Prendi questo scenario
9:46
Speaker 2: con data di inizio e data di fine. In un
9:47
Speaker 2: test di laboratorio inserisci una data di inizio lungo la domaggio,
9:49
Speaker 2: una data di fine il 30 aprile e la tua
9:51
Speaker 2: regola la contrassegna immediatamente. Perfetto. ma in produzione qualcuno inserisce
9:55
Speaker 2: i valori in un ordine diverso, modifica un record esistente
9:57
Speaker 2: in cui i campi sono già parzialmente compilati. Improvvisamente la
10:00
Speaker 2: convalida non si attiva fino al salvataggio o si attiva
10:02
Speaker 2: prima che l'utente abbia finito di digitare. Ciò crea confusione.
10:05
Speaker 2: Premono invia, vedono un messaggio di errore, correggono l'errore, premono
10:08
Speaker 2: di nuovo invia e poi il modulo genera un messaggio
10:10
Speaker 2: diverso per qualcos'altro. Questi errori sovrapposti sembrano casuali all'utente ma
10:14
Speaker 2: spesso sono solo le regole che si attivano in un
10:15
Speaker 2: ordine imprevisto. Un altro problema comune si verifica quando le
10:18
Speaker 2: regole si sovrappostano. Forse hai scritto una formula per verificare
10:20
Speaker 2: se i campi obbligatori sono compilati e un'altra per verificare
10:23
Speaker 2: le relazioni tra i valori. Se entrambe vengono attivate contemporaneamente,
10:26
Speaker 2: l'utente potrebbe visualizzare due banner di errore contemporaneamente. O ancora peggio,
10:30
Speaker 2: un messaggio nasconde l'altro. In alcuni casi, gli utenti più
10:33
Speaker 2: intelligenti scoprono rapidamente di poter ignorare completamente la combattita di
10:36
Speaker 2: Power Apps utilizzando le scelte rapide da tastiera facendo clic
10:38
Speaker 2: all'esterno del modulo o salvando la visualizzazione diversa in Sherpa.
10:42
Speaker 2: Per loro sembra che il modulo non funzioni. Per te,
10:44
Speaker 2: in quanto creatore, sembra che le regole su cui ti
10:45
Speaker 2: sei impegnato non vengano rispettate. Entrambe le frustrazioni sono reali.
10:49
Speaker 2: Ad aumentare la complessità c'è SharePoint stesso. PowerApps non sostituisce
10:52
Speaker 2: il modo in cui SharePoint applica le restrizioni sulle colonne.
10:55
Speaker 2: Se una colonna è SharePoint obbligatoria, SharePoint applicherà comunque tale requisito,
10:58
Speaker 2: indipendentemente dalla logica presente in PowerApps. La parte rischiosa si
11:01
Speaker 2: verifica quando le regole di convalida non corrispondono al modo
11:03
Speaker 2: in cui SharePoint interpreta lo stesso campo. Ad esempio, potresti
11:06
Speaker 2: consentire stringhe vuote in PowerApps perché controlli solo i campi visibili.
11:10
Speaker 2: Nel frattempo, SharePoint rifiuta di accettare lo stesso record perché
11:12
Speaker 2: la rettiva colonna è contrassegnata come obbligatoria, anche se il
11:14
Speaker 2: campo non è stato visualizzato nel modulo personalizzato. Il risultato
11:17
Speaker 2: è un errore di sicurezza. che non mostra alcun errore
11:20
Speaker 2: significativo all'utente. Viene visualizzata solo un'icona che gira con un
11:22
Speaker 2: messaggio generico che indica che non è possibile salvare. Questa
11:24
Speaker 2: lacuna tra le regole di Power Apps e l'applicazione di
11:27
Speaker 2: SharePoint è ciò che erode rapidamente la fiducia. Agli utenti
11:30
Speaker 2: non interessa se l'errore provenga dalla formula dal backend di SharePoint.
11:34
Speaker 2: Vedono solo che un modulo di cui si fidavano ha
11:35
Speaker 2: iniziato a rifiutare il loro input. È come costruire una
11:38
Speaker 2: diga che sembra solida nei test in giardino, ma nel
11:40
Speaker 2: momento in cui la riempi d'acqua su larga scala iniziano
11:42
Speaker 2: ad apparire piccole perdite in punti inaspettati. Ogni perdita di
11:46
Speaker 2: per sé sembra gestibile, ma lo schema invia un segnale.
11:48
Speaker 2: Questa struttura non è affidabile. Puoi immaginare cosa ciò comporti
11:51
Speaker 2: per l'adozione. Dopo qualche brutta esperienza, le persone smettono del
11:54
Speaker 2: tutto di inserire dati oppure iniziano a inventare soluzioni alternative
11:56
Speaker 2: per evitare di toccare moduli. Questo è il punto in
11:58
Speaker 2: cui i professionisti spesso trascorrono più tempo a risolvere i problemi.
12:01
Speaker 2: Non sulla progettazione, non su layout, ma sulla ricerca del
12:03
Speaker 2: motivo per cui determinati casi limite generano stati imprevedibili nel modulo.
12:07
Speaker 2: Si finisce per testare 20 diverse combinazioni di input, solo
12:10
Speaker 2: per capire come si attivano le regole... E più si
12:12
Speaker 2: va a fondo, più ci si rende conto che la
12:14
Speaker 2: convalida non consiste nello scrivere una o due formule precise.
12:17
Speaker 2: Si tratta di sovrapporre i controlli in modo da tenere
12:18
Speaker 2: conto del comportamento degli utenti, delle limitazioni di SharePoint e
12:21
Speaker 2: dei casi limite che non è possibile prevedere finché il
12:22
Speaker 2: modulo non è già stato distribuito. L'approccio più efficace è
12:25
Speaker 2: pensare alla convalida a livelli. Un livello in Power Apps
12:28
Speaker 2: per un feedback immediato. un altro in SharePoint per garantire
12:31
Speaker 2: l'integrità dei dati indipendentemente da come viene salvato il record
12:34
Speaker 2: e quindi ulteriori test non solo con voci pulite ma
12:36
Speaker 2: anche con la realtà caotica degli utenti che modificano nuovamente
12:39
Speaker 2: i record saltano i campi facoltativi o immettono dati che
12:41
Speaker 2: abbracciano anni anziché settimane se si supportano le regole con
12:44
Speaker 2: le impostazioni di SharePoint e si considera la convalida di
12:47
Speaker 2: PowerApps come la prima difesa anziché come l'unica si creano
12:49
Speaker 2: barriere di protezione anziché barriere fragili il punto chiave è
12:52
Speaker 2: questo la convalida non fallisce perché le regole sono sbagliate
12:56
Speaker 2: Fallisce perché non sono allineate tra Power Apps e SharePoint
12:58
Speaker 2: o perché vengono testate solo in condizioni perfette. L'affidabilità deriva
13:02
Speaker 2: dalla stratificazione degli errori, non solo dalla codifica per il
13:04
Speaker 2: percorso felice. Ed è esattamente qui che vediamo emergere i
13:07
Speaker 2: divari di affidabilità più ampio. Tra moduli creati in modo
13:11
Speaker 2: nativo e in SharePoint che applicano semplicemente le regole e
13:13
Speaker 2: moduli personalizzati di Power Apps che distreggiano tra flessibilità e imprevedibilità.
13:18
Speaker 2: Moduli nativi contro Power Apps. Stabilità contro flessibilità. Se i
13:22
Speaker 2: moduli predefiniti di SharePoint gestiscono il lavoro immediatamente, perché preoccuparsi
13:25
Speaker 2: di sostituirli con Power Apps in primo luogo? Questa è
13:28
Speaker 2: la domanda che la maggior parte di noi si pone
13:29
Speaker 2: una volta che l'entusiasmo per la persona svanisce. Moduli nativi
13:32
Speaker 2: di SharePoint possono sembrare semplici, ma non si interrompono quasi mai.
13:35
Speaker 2: Ottiene una convalida di input affidabile, un render incoerente su
13:38
Speaker 2: tutti i dispositivi e nessuna manutenzione aggiuntiva. Compromesso è che
13:40
Speaker 2: sono rigidi, Se vuoi che un campo venga visualizzato solo
13:42
Speaker 2: in determinate condizioni, che si adattino di sezioni, che si
13:44
Speaker 2: adattino dinamicamente alle regole aziendali, l'opzione predefinita è la regola aziendale.
13:47
Speaker 2: L'opzione predefinita non ti consentirà di ottenere questo risultato. Power
13:49
Speaker 2: Apps promette di colmare questa lacuna offendoti il controllo su logica,
13:52
Speaker 2: layout e automazione in modo che SharePoint da solo non
13:54
Speaker 2: può raggiungere. Il contrasto è evidente nel momento in cui
13:56
Speaker 2: li provi uno accanto all'altro. Un modulo di SharePoint predefinito
13:59
Speaker 2: si apre all'istante e non richiede alcuna configurazione e applica
14:01
Speaker 2: impostazioni di elenco semplici. Ma la progettazione è bloccata. Non
14:04
Speaker 2: puoi dire mostra questo campo solo se il richiedente è
14:07
Speaker 2: un responsabile o comprimere questi campi quando viene scelta una
14:09
Speaker 2: determinata risposta. Power Apps interviene offrendo questa flessibilità. Voi elenchi
14:14
Speaker 2: a discesa e a cascata collegate in un elenco di ricerca.
14:16
Speaker 2: Nessun problema. Voi sezioni che si visualizzano solo quando vengono
14:19
Speaker 2: soddisfatte determinate condizioni. Bastano un paio di forme. È una
14:22
Speaker 2: cosa stimolante, ma con queste libertà arriva una sorta di
14:24
Speaker 2: instabilità che non vedi fino a più tardi. Ecco dove
14:27
Speaker 2: sta il dilemma. Stabilità o flessibilità? Puoi scegliere un percorso
14:31
Speaker 2: noioso ma coerente, oppure puoi seguire la strada che offre
14:33
Speaker 2: esattamente l'esperienza utente che hai immaginato ma che potrebbe frustrarti
14:37
Speaker 2: in seguito quando si presentano problemi. In un progetto di
14:41
Speaker 2: modulo di richiesta la scelta è caduta sulla flessibilità. Desideravo
14:44
Speaker 2: una visibilità condizionale. Alcuni tipi di richiesta necessitavano di un
14:47
Speaker 2: pannello di informazioni aggiuntivo, mentre altri no. In SharePoint nativo
14:51
Speaker 2: ciò non era possibile senza creare moduli separati. Power Apps
14:54
Speaker 2: sembrava la soluzione ovvia. Durante lo sviluppo e le demo
14:57
Speaker 2: iniziali il modulo ha funzionato benissimo. Selezionando il viaggio è
15:00
Speaker 2: stata attivata una sezione per i dettagli debole. Selezionando l'hardware
15:03
Speaker 2: quei campi sono stati sostituiti con le specifiche dell'attrezzatura. Sembrava
15:06
Speaker 2: fatto su misura per il processo in un modo che
15:07
Speaker 2: le soluzioni pronte all'uso non avrebbero mai potuto. La svolta
15:09
Speaker 2: è arrivata con l'implementazione. Tutto ha funzionato senza problemi nei
15:12
Speaker 2: browser desktop, ma nel momento in cui gli utenti hanno
15:14
Speaker 2: provato a inviare dispositivi mobili l'illusione si è inclinata. Le
15:17
Speaker 2: sezioni non erano allineate e i pulsanti scivolavano sotto il
15:19
Speaker 2: bordo dello schermo. Alcune logiche condizionali si attivavano in modo
15:21
Speaker 2: incoerente a seconda del client model. Funzionalità che il modulo
15:24
Speaker 2: predefinito di SharePoint gestiva senza problemi, come rendere incoerente tra
15:27
Speaker 2: i vari fattori di forma, si sono improvvisamente trasformate in
15:29
Speaker 2: punti critici. Per risolvere queste stranezze abbiamo dovuto ripensare parti
15:33
Speaker 2: del design, testare con più app per dispositivi mobili e
15:35
Speaker 2: accettare che alcuni utenti avrebbero sempre avuto un'esperienza meno prevedibile.
15:38
Speaker 2: Questo era un prezzo che il team non aveva considerato
15:40
Speaker 2: quando si è messo alla ricerca della flessibilità. Ed è
15:42
Speaker 2: un promemoria di qualcosa che è facile trascurare. Stabilità non
15:45
Speaker 2: significa solo che non si blocca. Significa comportamento coerente in
15:49
Speaker 2: qualsiasi scenario in cui si imbattono gli utenti. La pressione
15:52
Speaker 2: che spinge le persone verso Power Apps è solitamente la
15:54
Speaker 2: logica Z. I processi reali raramente rientrano in un modulo generico.
15:58
Speaker 2: Elementi come requisiti condizionali, valori predefiniti, precompilati o approvazioni in
16:01
Speaker 2: più passaggi è lontano dai moduli naturali. I flussi di
16:04
Speaker 2: lavoro integrati con Power Automate funzionano meglio quando vengono attivati
16:06
Speaker 2: da campi e regole personalizzati definiti tramite Power Apps. Ecco perché,
16:10
Speaker 2: nonostante i rischi, le organizzazioni continuano a cambiare i loro moduli.
16:14
Speaker 2: Non è perché Power Apps ha un aspetto migliore, è
16:15
Speaker 2: perché i suoi moduli nativi spesso non sono in grado
16:17
Speaker 2: di gestire i processi aziendali effettivi senza piegarli ai limiti
16:20
Speaker 2: della tecnologia. Tuttavia, voce esperta nella community sottolinea un pericolo.
16:25
Speaker 2: L'utilizzo di Power Apps per modifiche estetiche come la riorganizzazione
16:28
Speaker 2: dei campi o l'ottimizzazione dell'aspetto del modulo raramente giustifica il passaggio.
16:32
Speaker 2: Le modifiche estetiche sono il motivo meno prezioso e più
16:34
Speaker 2: rischioso per adottare Power Apps. Se il tuo caso aziendale
16:37
Speaker 2: è semplicemente quello di migliorare l'aspetto, potresti finire per sacrificare
16:40
Speaker 2: la coerenza per un guadagno duratura molto limitato. Senza una
16:43
Speaker 2: solida motivazione basata sulla funzionalità, l'affidabilità persa può superare di
16:47
Speaker 2: gran lunga i vantaggi. E questa è la verità nascosta.
16:50
Speaker 2: L'affidabilità solitamente diminuisce quando sostituisci una soluzione nativa semplicemente perché
16:54
Speaker 2: Power Apps è disponibile, non perché la soluzione è giusta.
16:56
Speaker 2: Sostituisci un modulo che funziona semplicemente con un modulo che
16:58
Speaker 2: richiede la tua attenzione continua. Ogni nuovo campo rischia di
17:01
Speaker 2: rompere una formula. Ogni aggiornamento della piattaforma richiede una nuvità.
17:05
Speaker 2: Il costo non è immediato, ma è la manutenzione a
17:07
Speaker 2: lungo termine e la frustrazione. La chiave non è evitare
17:10
Speaker 2: Power Apps del tutto, ma rimanere intenzionali. Chiediti se la
17:13
Speaker 2: personalizzazione offre un valore che SharePoint non può offrire in
17:15
Speaker 2: nessun altro modo. Se lo fa, vale la pena pianificare
17:18
Speaker 2: la complessità aggiuntiva. In caso contrario, manteniamo la domanda. Una
17:21
Speaker 2: soluzione sufficientemente buona e stabile batte quasi sempre una soluzione
17:24
Speaker 2: intelligente che collassa con l'uso quotidiano. Quindi la vera decisione
17:27
Speaker 2: non è semplicemente tra SharePoint e Power Apps, ma... Riguarda
17:30
Speaker 2: la consapevolezza di quando attenersi alla fidabilità di base e
17:31
Speaker 2: quando accettare i rischi di passare a una personalizzazione. Perché
17:34
Speaker 2: una volta che si passa a una personalizzazione si affrontano
17:36
Speaker 2: sfide che non si possono migliorare e il successo dipende
17:37
Speaker 2: dal fatto che le si sia previste. E questo ci
17:39
Speaker 2: porta direttamente alla domanda più importante. Se si decide di
17:42
Speaker 2: utilizzare Power Apps, quali strategie possono impedire che il modulo
17:45
Speaker 2: diventi fragile nel tempo? Strategie pratiche per moduli Power Apps resistenti.
17:50
Speaker 2: Quindi se i moduli Power Apps sono fragili, cosa serve
17:52
Speaker 2: effettivamente per crearne uno che duri? Questa è la parte
17:54
Speaker 2: che molte persone salta. Passano direttamente dalla progettazione all'implementazione pensando
17:58
Speaker 2: che una manciata di correzioni di bug manterrà stabile il modulo.
18:01
Speaker 2: La realtà è che la stabilità non riguarda la riparazione
18:03
Speaker 2: di singole crepe, ma la definizione delle fondamenta prima ancora
18:06
Speaker 2: che si formino. L'ho imparato sulla mia pelle con un
18:09
Speaker 2: modulo di richiesta che continuava a rallentare indipendentemente da quante
18:11
Speaker 2: modifiche portassi. La versione che ha finalmente letto è stata
18:14
Speaker 2: quella creata con disciplina fin dall'inizio piuttosto che con soluzioni
18:17
Speaker 2: intelligenti alla fine. La prima strategia consiste nel mantenere la
18:19
Speaker 2: logica leggera. Ogni formula aggiunta in Power Apps sembra piccola
18:22
Speaker 2: se presa isolatamente, ma è un altro elemento di elaborazione
18:24
Speaker 2: che viene eseguito in tempo reale sul dispositivo di un utente.
18:27
Speaker 2: Se ne aggiungi troppo, il tuo modulo diventa lento. L'offload
18:30
Speaker 2: può fare la differenza tra qualcosa che dura e qualcosa
18:32
Speaker 2: che va in pezzi. Power Automate è più adatto per
18:35
Speaker 2: operazioni più pesanti come l'invio di mail, la creazione di
18:38
Speaker 2: elementi correlati o l'avvio di flussi di lavoro. Il sistema
18:41
Speaker 2: può gestire questa attività in background, lasciando il modulo di
18:43
Speaker 2: Power Apps a livello di concentrarsi sull'input e sulla presentazione.
18:46
Speaker 2: Lo stesso vale per SharePoint stesso. Se un campo deve
18:48
Speaker 2: sempre contenere un indirizzo email valido, lascia che SharePoint imponga
18:51
Speaker 2: quel tipo di colore. Evita di duplicare le regole in
18:53
Speaker 2: Power Apps a meno che tu non abbia bisogno di
18:55
Speaker 2: un feedback visibile. In secondo luogo, non limitarti a testare
18:58
Speaker 2: con i 5 record aggiunti per lo sviluppo. Crea il
19:00
Speaker 2: tuo piano di test con dati su scale di produzione.
19:02
Speaker 2: Se prevedi migliaia di righe nell'elenco sottostante, carica le migliaia
19:05
Speaker 2: durante il test. Moduli che sembrano reattivi in anteprima possono
19:09
Speaker 2: comportarsi in modo molto diverso quando vengono estratti da un
19:11
Speaker 2: elenco che contiene già mesi di richieste o allegati dimensioni.
19:14
Speaker 2: Il calo delle prestazioni si nota solo su larga scala e,
19:16
Speaker 2: se lo rilevi prima dell'implementazione, ti risparmi il fastidioso ciclo
19:19
Speaker 2: di feedback degli utenti che scoprono il ritardo durante il
19:21
Speaker 2: lavoro quotidiano. Ciò può sembrare noioso, ma spesso rivela prima
19:24
Speaker 2: i colli di bottiglia e ti dà il tempo di
19:26
Speaker 2: semplificare i calcoli o ridurre il numero di controlli su
19:28
Speaker 2: una singola schermata. Una terza salvaguardia ha più livelli. Power
19:32
Speaker 2: Apps dovrebbe gestire l'aspetto intuitivo della convalida, guidando gli utenti,
19:36
Speaker 2: mostrando messaggi istantanei, evidenziando un campo mancante, ma le restrizioni
19:39
Speaker 2: di SharePoint devono supportare tali regole. Considerale come due porte
19:42
Speaker 2: che devono essere chiuse che a una. Se la convalida
19:45
Speaker 2: di Power Apps non riesce a rilevare una voce errata,
19:47
Speaker 2: SharePoint applica comunque l'integrità prima che il record venga salvato.
19:50
Speaker 2: Questo approccio a più livelli evita quella lacuna in cui
19:52
Speaker 2: Power Apps afferma che qualcosa è corretto, ma SharePoint lo
19:54
Speaker 2: rifiuta silenziosamente. Ciò significa anche che la reportistica rimane coerente,
19:58
Speaker 2: perché la qualità dei dati non si basa esclusivamente sul
20:00
Speaker 2: fatto che le persone inseriscano il modulo nel modo previsto. 4.
20:03
Speaker 2: Documenta le tue formule man mano che progetti. Sembra noioso,
20:06
Speaker 2: ma il tuo futuro, tu, o peggio ancora il collega
20:08
Speaker 2: che reddita il modulo, perderà ore a cercare di sbrogliare
20:10
Speaker 2: un'espressione che al momento sembrava ovvia. Anche una breve riga
20:14
Speaker 2: di spiegazioni su formule complesse può evitare molta confusione in seguito.
20:19
Speaker 2: Commentare il codice non è affascinante, ma in Power Apps
20:21
Speaker 2: è più importante perché le formule spesso si confondono all'interno
20:23
Speaker 2: delle proprietà. Senza note, dimenticherai perché hai scritto una regola
20:26
Speaker 2: in un modo particolare ed esiterai a toccarla anche quando
20:29
Speaker 2: ne hai bisogno. La documentazione mantiene il tuo modulo gestibile.
20:32
Speaker 2: Infine resiste alla tentazione di passare a un'implementazione completa. Esegui
20:35
Speaker 2: l'implementazione in fasi gestibili. Invia prima il modulo a un
20:37
Speaker 2: gruppo pilota, lascia che lo utilizzi in condizioni reali e
20:39
Speaker 2: ascolta attentamente il suo feedback. Scoprirai casi limite, inconvenienti dalle
20:44
Speaker 2: prestazioni e comprenderai il comportamento reale degli utenti prima che
20:47
Speaker 2: l'intera organizzazione dipenda da esso. L'iterazione in fasi crea fiducia
20:51
Speaker 2: e ti dà lo spazio per correggere la struttura sottostante
20:53
Speaker 2: senza la pressione di tutti che chiedono affidabilità fin dal
20:55
Speaker 2: primo giorno. Ciò che lega insieme tutti questi passaggi è
20:58
Speaker 2: la disciplina. Non puoi sfuggire completamente dalla complessità una volta
21:01
Speaker 2: aperto un modulo di SharePoint in PowerApp.