Si desidera creare moduli in Salesforce Platform? Sono disponibili più opzioni, che si estendono dall'intero low-code al continuum pro-code. I moduli dinamici nel Generatore di app Lightning e i flussi schermata in Flow Builder sono una rappresentazione low-code. A metà del continuum si trova la possibilità di estendere i flussi schermata con i componenti LWC e di creare moduli indirizzati ai clienti con OmniStudio. E a rappresentare pro-code è il framework LWC e la sua libreria in continua crescita di componenti di base.

Le opzioni sono ottime, ma come determinare quale (o quale combinazione) è l'opzione giusta? È qui che entra in gioco questa guida.

• Takeaway #1: Quando si creano/modificano/visualizzano layout per le pagine Lightning, utilizzare i moduli dinamici. Si può notare che i layout di pagina mancano nelle tabelle di confronto di questa guida. In futuro, il modo consigliato per configurare le pagine dei dettagli dei record è utilizzare i moduli dinamici nel Generatore di app Lightning. Vedere la sezione sui layout di pagina per ulteriori informazioni sul motivo per cui non prevediamo di migliorarli ulteriormente.
• Takeaway #2: Se è necessario creare un modulo di creazione o modifica per un solo oggetto, iniziare con le pagine Lightning e i moduli dinamici. Questo è il modo più semplice per creare moduli nella piattaforma Salesforce. Fornisce anche alcune funzionalità aggiuntive, ad esempio la possibilità di controllare la visibilità dei campi. Se i requisiti sono più avanzati, continuare a leggere. Flusso schermata, OmniStudio o componenti Web Lightning (LWC) possono essere più adatti.
• Takeaway #3: Se si crea un modulo multipagina o una procedura guidata e non si hanno requisiti rigorosi per l'utilizzo dell'interfaccia utente o l'immagine aziendale, iniziare con un flusso schermata. I flussi schermata offrono un framework di navigazione lineare per orchestrare più moduli insieme. È possibile utilizzare LWC per creare il proprio framework per spostarsi tra i moduli, ma si consiglia di lasciare che sia il Flusso a fare il lavoro più impegnativo, in modo da potersi concentrare sui moduli stessi anziché preoccuparsi dello stato del modulo.
• Takeaway #4: Se sono necessarie ulteriori azioni o logica dietro il modulo, utilizzare un flusso schermata, OmniStudio o LWC. Tutti e tre gli strumenti offrono alla soluzione modi per fare di più che creare o modificare un singolo record. Quel "più" potrebbe essere una logica più avanzata, ad esempio la ramificazione o l'iterazione, o potrebbe essere più azioni come l'integrazione con sistemi esterni, l'invio di email o l'invio di notifiche push all'app mobile di un utente.
• Takeaway #5: Hai dei requisiti UX sofisticati? Hai bisogno di gestire dinamicamente più della visibilità? Utilizzare LWC o OmniScript. Se i propri requisiti possono essere soddisfatti con semplici layout basati su temi e colonne, è possibile creare i moduli direttamente in un generatore low-code. Per un controllo più preciso sullo stile della tua forma, avrai bisogno della massima flessibilità di LWC. Se si è un cliente di Settori e si necessita di un'immagine aziendale perfetta o di dati gerarchici complessi, utilizzare OmniStudio, che consentirà di creare moduli di livello consumer in grado di gestire logiche aziendali complesse e trasformazioni dei dati.
• Takeaway #6: Se è necessaria l'automazione dei test, iniziare con i componenti Web Lightning. È possibile scrivere test di unità per qualsiasi LWC, indipendentemente da dove si prevede di incorporarlo. Ciò consente di creare una strategia di test più efficace, che può includere test in blocco con più record e test negativi. Vedere Salesforce Well-Architected - Testing Strategy per ulteriori informazioni sulla creazione di test che consentono di vedere in che misura i moduli saranno allineati ai requisiti funzionali e non funzionali.

Tenere presente che la scelta non deve necessariamente essere una o l'altra: è possibile combinare la potenza di più opzioni. Ad esempio, se sono necessari sia il sistema di navigazione integrato di Flow che la completa flessibilità di stile offerta da LWC, utilizzarli insieme.

La tabella seguente descrive gli strumenti disponibili per la creazione di moduli con Salesforce, insieme alle competenze richieste e alle considerazioni sulla licenza. Più avanti approfondiremo le funzioni specifiche supportate per ogni strumento, oltre a capire come scegliere tra strumenti basati su clic e strumenti basati su codice (e quando combinarli):

La tabella seguente contiene una panoramica dei punti su cui riflettere quando si selezionano i prodotti, oltre alle domande che ci si dovrebbe porre su ciascuno di essi. Approfondiremo ciascuno di questi argomenti nel resto di questa guida.

Di seguito sono riportati i termini utilizzati nelle tabelle di confronto insieme alle relative definizioni:

• Disponibile: Funziona bene con le considerazioni di base.
• Non ideale: Può funzionare ma non è lo strumento ottimale.
• Roadmap: Sostegno stimato entro i prossimi dodici mesi (giugno 2025).
• Futuro: Stimata per il supporto oltre i prossimi dodici mesi.
• Non disponibile: Non si prevede di supportare questa funzionalità nei prossimi dodici mesi.

Come promesso, iniziamo un'analisi approfondita di una varietà di punti di confronto e differenze funzionali tra moduli dinamici, flussi schermata, OmniStudio, flussi schermata con LWC incorporati e il framework LWC stesso.

Se il modulo funziona con un singolo oggetto Salesforce, tutti gli strumenti che stiamo confrontando funzioneranno. Le cose si complicano leggermente con le forme oggetti incrociate o indipendenti dagli oggetti. Per indipendente dagli oggetti si intendono gli input che non vengono mappati ad alcun oggetto Salesforce. È possibile che il modulo rappresenti una struttura di dati che verrà inviata a un servizio esterno, ad esempio Stripe o DocuSign. Oppure si utilizzano diversi input nel modulo per calcolare un valore e quindi confermare quel valore nel database.

• Contro quali oggetti opererà il modulo?
• È solo un oggetto o ci sono più oggetti?
• Si lavora con oggetti specifici (ad esempio Account, Referente, Opportunità, Lead e Caso) o il modulo dovrà funzionare anche con altri oggetti?

Sia per i moduli oggetti incrociati che per quelli indipendenti dagli oggetti, Flusso e OmniStudio sono entrambe opzioni solide. Poiché i componenti disponibili nelle schermate dei flussi non sono di natura agnostica, è possibile scegliere cosa fare con i dati in background. Ad esempio, utilizzare i dati immessi in un modulo per creare più record in background, oppure utilizzarli per eseguire altre azioni come generare post Chatter, inviare messaggi Slack, inviare email o connettersi a servizi esterni.

Per i casi semplici, l'uso di componenti LWC esistenti, ad esempio Lightning-record-form, può essere un modo semplice per ridurre il codice necessario per fornire una soluzione efficace. Tuttavia, per gli scenari in cui sono coinvolti più oggetti, Flusso offre un controllo completo per tutti gli oggetti ed elimina la necessità per gli sviluppatori di attraversare relazioni e dipendenze complesse.

OmniStudio fa un ulteriore passo avanti ed è completamente indipendente dagli oggetti: separa il modulo visualizzato da un utente dal modello di dati sottostante. OmniStudio manipola invece il JSON sottostante che viene mappato agli oggetti Salesforce (o ai dati esterni) utilizzando strumenti come Data Mapper e Procedure di integrazione. Data Mapper e Procedure di integrazione sono due componenti chiave per la connessione dei moduli OmniStudio con i dati interni ed esterni a Salesforce. Utilizzando gli elementi di trascinamento della selezione, è possibile utilizzare dati gerarchici complessi in un sistema esterno e quindi trasformare i dati in base alle proprie esigenze a seconda di dove devono andare a finire i dati. Consentono anche di utilizzare le formule per eseguire operazioni matematiche e logiche su matrici o elenchi di dati, come Apex.

OmniStudio

Se è possibile ottenere tutti gli input utente da un modulo a schermata singola, iniziare con i moduli dinamici. Tuttavia, sebbene i moduli dinamici nelle pagine dei record possano utilizzare la funzione Percorso per rappresentare in modo poco chiaro le varie fasi del processo aziendale, è possibile che non si adatti alla maggior parte dei casi d'uso.

• È necessaria una schermata singola o l'utente dovrà spostarsi tra più schermate per completare un'operazione?
• Si desidera che gli utenti visualizzino una rappresentazione visiva dello stato di avanzamento della compilazione del modulo?
• Agli utenti verrà richiesto di compilare le informazioni su ogni schermata in un ordine specifico o di spostarsi avanti e indietro tra le schermate in base alle esigenze?

Se sono necessarie più funzionalità rispetto a quelle offerte dai moduli dinamici, la scelta tra Flusso, OmniStudio e LWC dipenderà anche da alcune altre domande:

• Quali competenze ha il team? Per un'organizzazione più complessa per gli amministratori, si consiglia di iniziare con Flusso. Se si dispone di soluzioni per i settori, il team ha già familiarità con OmniStudio e il progetto ha requisiti UX rigorosi, iniziare con OmniStudio.
• È possibile visualizzare una barra di navigazione in fondo al modulo? Se il flusso schermata e l'esperienza di navigazione OmniScript non sono desiderati, propendere per LWC.
• Cosa deve accadere dietro il modulo? Se è necessario che il comportamento sia configurabile da un amministratore, creare un flusso o, per le modifiche di base come la modifica delle etichette dei campi, un OmniScript. In caso contrario, per relazioni complesse tra più oggetti creare un OmniScript o LWC.
• Se si sceglie Flusso o OmniStudio, può essere necessario creare comunque un LWC per ottenere l'interfaccia utente corretta. Se si sta già creando un componente LWC per definire correttamente lo stile del modulo, valutare se incorporare quel componente in un flusso è eccessivo.

Se invece la soluzione si presenta come una procedura guidata, in cui l'utente naviga tra più schermate, considerare Flusso o OmniStudio. I flussi e OmniStudio sono dotati di un modello di navigazione integrato, quindi non è necessario creare e gestire componenti LWC collegati tra loro. La navigazione è lineare, con azioni di spostamento in avanti, azioni di spostamento all'indietro e un meccanismo per salvare il modulo per un secondo momento. È anche possibile creare un modulo con navigazione non lineare se adatto alle proprie esigenze. Per un ottimo esempio di utilizzo dei flussi schermata, consultare il pacchetto Digital Store Audit di Salesforce Labs.

OmniStudio offre un vantaggio di navigazione chiave fornendo indicatori di avanzamento dalla navigazione standard che evidenziano "passaggi" nel modulo. Questa visualizzazione fase visualizza automaticamente la posizione di un utente in un determinato modulo a più fasi. A differenza di Flusso, consente agli utenti di "saltare" tra le schermate facendo clic su varie fasi del modulo.

Indipendentemente dal fatto che si creino moduli a schermata singola o multischermo, assicurarsi che i moduli siano snelliti in modo che siano facili da navigare per gli utenti.

Se si incorpora un modulo in una pagina di record Lightning standard, tutti gli strumenti che stiamo confrontando funzioneranno, con l'avvertenza che i moduli dinamici sono attualmente disponibili solo su desktop. Tuttavia, se si desidera offrire un'esperienza che consenta agli utenti di accedere ai moduli da altre posizioni, potrebbe essere necessario considerare opzioni alternative.

• Gli utenti avranno bisogno di accedere al modulo tramite desktop, dispositivo mobile o entrambi?
• Gli utenti devono essere in grado di accedere al modulo da qualsiasi punto dell'app tramite una barra delle utilità?
• Si desidera utilizzare le azioni per consentire agli utenti di compilare il modulo senza dover uscire dalla pagina in cui si trovano attualmente?
• Il modulo deve essere disponibile su un sito Web esterno?

Poiché richiedono contesto record, i moduli dinamici sono supportati solo nelle pagine di record Lightning. Tuttavia, i moduli dinamici non sono supportati nelle pagine Experience Cloud. Questa limitazione è attiva perché Experience Cloud non utilizza il framework sottostante da cui dipendono i moduli dinamici: Pagine Lightning. Questo aspetto viene valutato in base alle richieste di moduli dinamici in Experience Cloud.

È possibile creare flussi che richiedono un contesto record o flussi che funzionano a livello globale. Pertanto, è possibile incorporare i flussi in una varietà di posizioni. Per i flussi contestuali di record, che possono essere una pagina di record Lightning, una pagina di record Experience Cloud, un'azione specifica di un oggetto o una distribuzione Azioni e Consigli. Per il flusso globale, ad esempio la barra delle utilità, altre pagine Lightning o Generatore di esperienze, uno Snap o un'applicazione esterna. I flussi non sono attualmente supportati come azioni globali, ma come soluzione è possibile racchiudere il flusso in un componente Aura.

OmniStudio consente di creare FlexCard e OmniScript componibili che possono essere posizionati praticamente ovunque sia possibile inserire un flusso. Tuttavia, sebbene siano componibili, non sono inseribili in pacchetti.

LWC supporta un elevato grado di riutilizzo, poiché si creano componenti che possono essere associati ai target tramite metadati in Salesforce, nelle comunità e persino nei progetti open source. I componenti LWC possono anche essere incorporati all'interno del proprio sito Web tramite Lightning Out.

Lightning Out sui siti esterni

I componenti Web Lightning non sono attualmente supportati come azioni (specifiche degli oggetti o globali), ma come soluzione si può racchiudere un componente LWC in un componente Aura (in modo molto simile ai flussi). I componenti LWC possono anche lanciare flussi con il componente Lightning-flow.

OmniStudio eccelle nell'esposizione dei contenuti ai siti esterni tramite la funzione OmniOut. Con OmniStudio e OmniOut è possibile compilare i moduli OmniScript e i componenti FlexCard in componenti standard ed eseguirli fuori piattaforma in siti o app di terze parti.

Nessuna delle tecnologie dei moduli trattate in questa guida è oggi ufficialmente supportata nei modelli Mobile SDK. Se Mobile SDK è essenziale per il proprio caso d'uso, è meglio creare il modulo in modo nativo nell'applicazione mobile o creare una pagina Visualforce, pur tenendo presente la guida al fattore di forma ben progettato di Salesforce.

Nota sulla roadmap: Il team Mobile SDK sta lavorando attivamente al supporto dei componenti LWC all'interno delle pagine Visualforce.

I moduli dinamici sono perfetti se è necessario utilizzare i valori del modulo per creare o aggiornare un record. Per qualsiasi funzionalità oltre a questa, è necessario utilizzare Flusso, OmniStudio o LWC. Queste funzionalità possono includere un livello di decisione o iterazione o la generazione di post o email Slack utilizzando gli input del modulo.

• Quali azioni o logica si desidera eseguire dietro le quinte?
• Il modello di dati contiene dati gerarchici?
• Il modulo dovrà completare le operazioni all'interno di una singola transazione o in più transazioni?
• È necessario integrarsi con sistemi esterni?
• Quali sono i requisiti di riutilizzabilità e modularità?

Il flusso offre azioni standard per la pubblicazione in Slack, l'invio di email e l'interazione con i documenti Quip, quindi non è necessario scrivere codice per queste operazioni. LWC offre interazioni complete con singoli record e oggetti correlati tramite l'uso di adattatori di fili che interagiscono con l'API interfaccia utente. LWC può anche interagire con più record quando si utilizza il wire per getListInfoByName.

Interazione dei componenti Web Lightning tramite adattatori per cavi

Come accennato in precedenza, OmniStudio utilizza Procedure di integrazione e Data Mapper per acquisire e trasformare facilmente i dati esterni e interni a Salesforce. Brilla nell'appiattimento e nell'espansione delle serie di dati con vari livelli di relazioni grazie a numerose funzioni senza codice che è possibile utilizzare.

Nota sulla roadmap: Il flusso supporterà presto la possibilità di up-inserire raccolte di record e di gestire i dati gerarchici.

Flusso, OmniStudio e LWC si integrano tutti con Apex, quindi è possibile chiudere facilmente eventuali lacune in qualsiasi soluzione si scelga. Ad esempio, se è necessario filtrare i record da un LWC è sempre possibile utilizzare l'adattatore per fili per Apex per creare query SOQL complesse. Se si è influenzati dalla storia basata sui clic, considerare Flusso o OmniStudio come valide alternative a un controller Apex per le esigenze lato server.

Una domanda secondaria è se si desidera confermare immediatamente le azioni o rinviarle a una particolare parte del modulo. Questo è particolarmente rilevante se si utilizza un modulo multipagina. Il flusso consente di combinare facilmente gli input di più moduli (schermate del flusso) e di utilizzarli molto più avanti nella procedura guidata (flusso) per eseguire alcune operazioni. Si consiglia infatti di progettare i flussi proprio in questo modo (eseguire le azioni alla fine) nel caso in cui l'utente salti avanti e indietro tra le schermate, modificando le risposte.

Le transazioni e i limiti del governor sono uno stile di vita in Salesforce Platform. Se il caso d'uso è abbastanza semplice, potrebbe non essere altrettanto importante controllare in quale transazione si verifica una determinata operazione. Tuttavia, esistono alcuni casi d'uso in cui è possibile combinare più operazioni in un'unica transazione anziché eseguirle in più transazioni. Alcuni esempi:

• Per ritirare o non ritirare: Questa è la domanda. Si supponga che il modulo crei più record in background. Se non viene creato il terzo record, è necessario ritirarne i primi due? Se ogni azione è indipendente l'una dall'altra, è possibile eseguirla in transazioni separate. Tuttavia, se sono dipendenti e si desidera che l'errore di uno esegua anche il ritiro degli altri, implementarli in un'unica transazione. Se il modulo è in Flusso, è possibile utilizzare l'elemento Rollback in un percorso di errore per ritirare la transazione e garantire l'integrità dei dati.
• Impatto a valle sui limiti del governor: Soprattutto quando il modulo crea o aggiorna un record, tenere presenti le implicazioni a valle di tale operazione. Quali processi, regole di flusso di lavoro, trigger di flusso, trigger Apex o altri elementi dell'ordine di salvataggio verranno attivati in base a questa modifica del record? E in che modo queste modifiche collettive influiscono sui limiti del governor consumati in quella transazione? Se una particolare modifica del record comporterebbe numerose modifiche a valle che influiscono sui limiti, valutare se è opportuno isolare la modifica del record nella propria transazione.
• Elaborazione batch: Anche nel contesto di un'interfaccia utente, può essere necessario raggruppare in batch più aggiornamenti. Si supponga che il modulo multischermo esegua l'iterazione su un gruppo di record di grandi dimensioni. Anziché confermare un aggiornamento di record dopo ogni schermata, attendere di aver raccolto gli aggiornamenti per tutti i record e quindi inviare una richiesta per aggiornare tutti i record.

Quando si utilizzano i moduli dinamici per creare o modificare un record, si esegue sempre una sola operazione, che è sempre l'inizio di una nuova transazione.

Quando si crea un flusso schermata, si ha un controllo significativo su ciò che accade in una determinata transazione. Le schermate e le azioni locali fungono da confini tra le transazioni. Di seguito è riportato un riepilogo generale della gestione delle transazioni nell'architettura del flusso schermata.

1. L'utente finale interagisce con una schermata e quindi fa clic su Avanti.
2. Il client invia una richiesta all'API con gli input.
3. L'API riceve la richiesta e viene aperta una transazione e una connessione al database. L'API chiama quindi il motore di flusso per invocare la richiesta.
4. Il motore di flusso prende il sopravvento e segue il percorso appropriato nella definizione del flusso, fino a quando non colpisce un nodo Schermata o Azione locale. Il motore restituisce quindi le informazioni su quel nodo all'API.
5. L'API crea un oggetto risposta che contiene i dettagli della schermata successiva da visualizzare e restituisce l'oggetto al client. A questo punto vengono confermate le modifiche al database (avvio dell'esecuzione dell'ordine di salvataggio) e la connessione al database e la transazione vengono chiuse.
6. Il client utilizza la risposta API per visualizzare la schermata successiva con cui l'utente può interagire.
7. Ripetere il passaggio 1.

In altre parole, le schermate "interrompono" le transazioni. In questo caso, vengono confermate tutte le azioni in sospeso o DML, la transazione precedente viene chiusa e viene avviata una nuova transazione.

La progettazione corretta, ovvero le operazioni raggruppate in una determinata transazione, è la chiamata. Vediamo alcuni esempi.

A sinistra è visibile un flusso che raccoglie gli input in più schermate ed esegue diverse azioni in un'unica transazione.

Il flusso a destra esegue ogni operazione in una transazione separata.

Si supponga di avere un flusso che crea record, aggiorna record e quindi crea altri record, come illustrato nel flusso successivo a destra.

In questo scenario, se i primi due elementi hanno esito positivo e l'ultimo ha esito negativo, le prime due operazioni DML continueranno a creare e aggiornare tali record, mentre il terzo non lo farà.

Utilizzando l'elemento Ritira record, è possibile assicurarsi che l'intera transazione venga ritirata se tutte e tre le operazioni devono avvenire in tandem, come illustrato nel flusso finale a sinistra.

Per ulteriori informazioni, vedere Flussi nelle transazioni e Bulkificazione dei flussi. Anche la sezione Automatica di Salesforce Well-Architected approfondisce questo aspetto in Gestione dei dati.

La possibilità di controllare la transazione da un LWC si riduce ai servizi sottostanti utilizzati da LWC per eseguire le proprie operazioni. Se si utilizza il componente Lightning-record-form base, l'operazione sottostante (creazione o aggiornamento del record) avviene in una transazione indipendente non appena viene inviato il modulo.

In generale, valgono le seguenti regole:

• Ogni chiamata API dell'interfaccia utente è isolata nella propria transazione.
• Se è necessario eseguire più operazioni all'interno di una singola transazione, inviare gli input a una tecnologia lato server, ad esempio un controller Apex o un flusso. Si applicano le normali regole di transazione per quella tecnologia.

Flusso, OmniStudio e LWC supportano tutti gli eventi piattaforma (per l'architettura basata sugli eventi) e le integrazioni API. Oltre all'Apex Code personalizzato, sia Flow che OmniStudio supportano meccanismi dichiarativi per integrare un'API.

Se è necessario connettersi a un'API Mulesoft o a un bot RPA, utilizzare i Servizi Mulesoft. Questo genera un servizio esterno.

Integrazioni esterne tramite API Mulesoft e bot RPA

Se l'API ha uno schema OpenAPI, creare un servizio esterno.

Integrazioni esterne tramite OpenAPIIntegrazioni esterne alle API con schemi OpenAPI __

In caso contrario, utilizzare la funzione Chiamata HTTP nel flusso o Azione HTTP in OmniStudio. La chiamata HTTP del flusso è basata su Servizi esterni.

Integrazioni esterne tramite HTTPIntegrazioni esterne tramite HTTP __

OmniStudio dispone di una serie completa di funzionalità di integrazione che possono effettuare chiamate a sistemi esterni con le procedure di integrazione e trasformare i dati con Data Mapper. (Per ulteriori informazioni, vedere Impatto sugli oggetti)

Indipendentemente dal fatto che venga implementata con Apex personalizzato o un servizio esterno, una chiamata è una chiamata. Ecco cosa devi sapere.

1. Una chiamata può richiedere molto tempo.
2. Quando una chiamata viene eseguita in modo sincrono, viene eseguita mentre è aperta una transazione del database.
3. Salesforce non consente di mantenere aperta una transazione del database se sono presenti operazioni del database in sospeso.

La limitazione principale da tenere presente è il pericolo delle cosiddette transazioni sporche, in cui si esegue un'operazione di creazione, aggiornamento o eliminazione e quindi, nella stessa transazione, si esegue una chiamata. Questo schema non è consentito a causa della considerazione #3 di cui sopra, che ovviamente esiste a causa delle considerazioni #1 e #2.

In Flusso, è possibile aggirare questa limitazione interrompendo la transazione. Ricordare che sia le schermate che le azioni locali reintroducono il contesto del browser, interrompendo la transazione. Sebbene sia possibile utilizzare schermate e azioni locali quando si utilizzano chiamate esterne, si consiglia di abilitare Controllo transazione nelle impostazioni avanzate invocabili. Controllo transazione è una funzione delle azioni invocabili che consente di terminare automaticamente la transazione prima di effettuare una chiamata. È possibile abilitare il controllo delle transazioni selezionando Avvia sempre una nuova transazione nella sezione Avanzate di un'azione invocata.

Per una guida più approfondita sulle chiamate Apex, i servizi esterni e le funzionalità di integrazione dei dati in generale, vedere la Architect's Guide to Data Integration with Salesforce.

I moduli dinamici non supportano il riutilizzo. Ogni modulo dinamico è collegato a una pagina di record Lightning specifica per un oggetto specifico (anche se è possibile assegnare la pagina di record Lightning a più app, profili e così via).

Così come è possibile scrivere librerie, utilità e componenti destinati a essere utilizzati in più altri componenti, è possibile applicare schemi di progettazione simili quando si creano flussi con la potenza dei sottoflussi. Salvare i flussi in bucket più piccoli e modulari e quindi chiamarli da altri flussi utilizzando l'elemento Sottoflusso. Se la progettazione lo richiede, è possibile creare un flusso che sia indipendente che utile come sottoflusso di un altro flusso.

OmniStudio è per sua natura progettato per la modularità. Mappatori di dati, OmniScript, FlexCard e Procedure di integrazione sono tutti creati in modo indipendente e possono funzionare in modo intercambiabile. Inoltre, le FlexCard possono essere create come componenti LWC che possono essere incorporati in altri LWC, OmniScript, pagine di record e siti Experience Cloud.

Flussi schermata, OmniScript e LWC possono essere tutti creati per essere riutilizzati e incorporati in una varietà di posizioni, inclusi siti esterni e applicazioni Lightning Out. Quando si progettano le soluzioni in modo che siano componibili si ottengono ulteriori vantaggi come l'adattabilità e la stabilità.

Tutte le tecnologie utilizzate per creare o aggiornare un record sono conformi alla convalida a livello di sistema, sia che si tratti di regole di convalida classiche o di convalida personalizzate incorporate in un trigger Apex. Indipendentemente dalla tecnologia utilizzata per eseguire una modifica del record, ogni modifica passa attraverso l'ordine di salvataggio. Ciò significa che, oltre alle regole di convalida, la modifica del record viene elaborata da un numero qualsiasi di flussi prima o dopo il salvataggio, prima o dopo trigger, regole di inoltro al livello superiore, regole di assegnazione e altro ancora. Se non l'avete già fatto, assicuratevi di inserire nei preferiti e di acquisire familiarità con l'ordine di esecuzione Apex.

• Il modulo ha ulteriori requisiti oltre alla convalida a livello di sistema?
• Sarà necessario impostare i campi in modo che siano obbligatori o di sola lettura in modo dinamico all'interno del modulo?

Gli input in una schermata del flusso o in una fase OmniScript non sono per loro natura vincolati, quindi il modulo stesso non aderisce in modo nativo alla convalida a livello di sistema associata a un particolare oggetto. I valori utilizzati per creare o aggiornare i record, tuttavia, vengono elaborati dall'ordine di salvataggio, ovvero passano attraverso la convalida a livello di sistema dell'oggetto. Tenere presente, tuttavia, che non tutti i componenti del flusso schermata supportano la convalida degli input. A partire dal rilascio Summer '24, i componenti schermata rimanenti che non supportano la convalida degli input sono Pulsanti di opzione, Elenco di selezione, Elenco di selezione a selezione multipla, Gruppo caselle di controllo e Ricerca scelte.

Proprio come i layout di pagina, i moduli dinamici consentono di impostare l'obbligatorietà e lo stato di sola lettura a livello di pagina. Tuttavia, non è possibile ignorare le impostazioni a livello di sistema.

Il flusso offre flessibilità per personalizzare la convalida sugli input di un modulo. Benché vengano eseguiti alcuni controlli nel client (ad esempio, la segnalazione di campi obbligatori mancanti o valori incompatibili), nessuna convalida lato client impedisce all'utente di provare a navigare. La vera convalida avviene sul server. Quando un utente fa clic su Avanti, Flusso invia gli input al server per la convalida. Se uno degli input viene restituito come non valido, la navigazione viene bloccata e viene visualizzato l'errore appropriato. Il server convalida gli input controllando:

1. L'impostazione della obbligatorietà dell'input o se il valore immesso è compatibile con il tipo di dati sottostante.
2. Convalida personalizzata per quell'input: Diversi componenti standard (casella di controllo, valuta, data, data/ora, area di testo lungo, numero, password e testo) supportano la convalida personalizzata per schermata. Fornire un'espressione di formula booleana e un messaggio di errore da visualizzare quando l'espressione di formula non viene soddisfatta.
3. Convalida personalizzata del componente sottostante: Se si sta creando un LWC personalizzato per un flusso, aggiungere il proprio codice di convalida al metodo validate().

OmniStudio offre una gestione completa degli errori e della convalida tramite l'azione Imposta errore in combinazione con Visualizzazioni condizionali e il componente Messaggistica.

Sul lato LWC, la maggior parte dei componenti di base esegue le proprie convalide lato client. Ad esempio, Lightning-record-form rispetta l'obbligatorietà a livello di sistema, ma non l'obbligatorietà a livello di pagina. Per i componenti personalizzati, è possibile Build Your Own meccanismi di convalida.

I campi che richiedono l'inserimento di dati da parte degli utenti devono essere visualizzati nelle prime fasi dei moduli. Ove possibile, convalidare gli input degli utenti sul lato client prima di inviare i moduli. Per ulteriori procedure consigliate per semplificare i moduli, vedere la guida ai moduli in Salesforce Well-Architected - Engaging.

La sicurezza è un argomento complesso in generale, e quando si tratta di creare moduli, ci sono una serie di considerazioni che potresti non aver nemmeno pensato. A livello di base, assicurarsi che il modulo venga eseguito nel contesto corretto e che gli utenti dispongano delle autorizzazioni necessarie per utilizzare i dati sottostanti. Ma oltre a ciò, è anche possibile adottare misure aggiuntive per eliminare codice o URL potenzialmente dannosi dai campi di testo RTF, impedire a determinati utenti di accedere al modulo o porre limitazioni ai tipi di posizioni in cui gli amministratori possono potenzialmente incorporare il modulo in futuro. Assicurarsi di documentare accuratamente i requisiti di sicurezza prima di scegliere uno strumento. Il modello Policy sulla sicurezza ben architettata di Salesforce contiene le linee guida per questo tipo di documentazione.

• Il modulo deve controllare l'accesso dell'utente prima di eseguire determinate operazioni?
• È necessario disinfettare gli input degli utenti?
• Si desidera controllare chi può accedere al modulo?
• Si desidera controllare dove può essere incorporato il modulo?

Quando qualcosa viene eseguito nel contesto dell'utente, Salesforce impone una serie di controlli dell'accesso, tra cui la verifica della protezione a livello di campo, delle autorizzazioni CRUD e dell'accesso ai record in base alle regole di condivisione dell'organizzazione. Quindi, ad esempio, gli utenti potrebbero eseguire un modulo di aggiornamento caso solo se hanno la possibilità di aggiornare i casi, la protezione a livello di campo appropriata e l'accesso al record in questione. Ma se si desidera che gli utenti siano in grado di eseguire una determinata operazione quando utilizzano il modulo, ma non tramite qualsiasi altro modulo o interazione? Qui entra in gioco il contesto di sistema.

Il contesto di sistema è un modo per elevare le autorizzazioni dell'utente in esecuzione per la durata della sessione, in modo che l'utente non debba, ad esempio, aggiornare l'accesso all'oggetto Caso per completare correttamente il modulo di aggiornamento del caso. Questo è particolarmente utile per le comunità non autenticate. Anziché concedere agli utenti guest competenze potenzialmente pericolose, impostare il modulo in modo che venga eseguito nel contesto di sistema.

Naturalmente, il contesto di sistema è un'arma a doppio taglio e si dovrebbe utilizzarlo solo quando necessario. Quando un modulo viene eseguito nel contesto di sistema, ogni singola operazione CRUD ignora la protezione e la condivisione a livello di oggetto e di campo, non solo l'operazione specifica che interessa. Si noti inoltre che il contesto di sistema non influisce su chi Salesforce considera l'attore, ovvero il nome visualizzato nel campo Ultima modifica di. Per ogni operazione eseguita dal modulo, ad esempio l'aggiornamento del caso, l'attore è l'utente in esecuzione anche se il modulo viene eseguito in un contesto diverso.

I moduli dinamici, gli OmniScript e i componenti LWC vengono sempre eseguiti nel contesto dell'utente e non è possibile ignorare questo comportamento.

I flussi schermata vengono eseguiti nel contesto dell'utente per impostazione predefinita, ma è possibile impostarli in modo che vengano eseguiti nel contesto di sistema. È l'utente a scegliere se il flusso deve concedere l'accesso a tutti i dati o se deve comunque imporre l'accesso a livello di record come la condivisione.

• Se si incorpora un componente Lightning in un flusso eseguito nel contesto di sistema, il flusso non sostituisce il contesto del componente. Se è necessario ignorare i controlli dell'accesso degli utenti, si consiglia di utilizzare il flusso per eseguire tali operazioni e trasmettere i dati appropriati al componente Lightning o al suo esterno. Alcuni componenti pronti all'uso (ad esempio Ricerca) non possono funzionare nel contesto di sistema.
• Se il flusso chiama azioni Apex, è necessario individuare altre differenze. Se la classe Apex è impostata sulla condivisione ereditata, viene eseguita nel contesto di sistema con la condivisione indipendentemente dall'impostazione del flusso. Se la classe non ha una dichiarazione di condivisione esplicita, viene eseguita nel contesto di sistema senza condivisione indipendentemente da quale sia l'impostazione del flusso. Se la classe è impostata su con condivisione o senza condivisione, lo fa e ignora il contesto del flusso.

Query per i record nel contesto di sistema con i siti Experience Cloud:

Se si esegue un flusso nel contesto di sistema in un sito Experience Cloud, soprattutto non autenticato, si consiglia di memorizzare solo campi specifici negli elementi Ottieni record. Quando si utilizza Flusso e si passano i risultati di un elemento Ottieni record in un sottoflusso, in un'azione invocabile o in un componente Lightning, tutti i campi di quell'oggetto possono essere esaminati tramite gli strumenti per sviluppatori del browser. Ciò potrebbe rendere disponibili i campi agli utenti del sito Experience Cloud che potrebbero non essere intenzionati. Specificando campi specifici negli elementi Ottieni record, è possibile assicurarsi che vengano visualizzati solo i campi corretti anche con il contesto di sistema abilitato.

Si noti che la logica OmniScript viene eseguita sul lato client, il che consente agli aggressori di modificare l'esecuzione prevista di un OmniScript e di visualizzare le risposte alle procedure di integrazione, ai data mapper e alle chiamate al metodo Apex utilizzando gli strumenti per sviluppatori del browser. Quando si utilizza OmniScript, si consiglia di eseguire la logica aziendale sul lato server quando possibile e di implementare regole di convalida degli input su qualsiasi metodo Apex esposto tramite un'annotazione @InvocableMethod.

Input sanificanti:

Per proteggere l'organizzazione dai malintenzionati, considerare anche la disinfettazione degli input. Si supponga di avere un input in un modulo accessibile pubblicamente che potrebbe essere mappato a un campo di testo RTF nell'organizzazione. Si consiglia di considerare un'automazione che elimini qualsiasi codice HTML che potrebbe nascondere URL dannosi. In generale, non è consigliabile implementare questa sanificazione a livello di modulo, poiché è possibile che un numero qualsiasi di fonti scriva in questi campi. Si consiglia di creare un flusso di aggiornamento rapido dei campi (prima del salvataggio) o di utilizzare un trigger Apex esistente sull'oggetto per eliminare o modificare il potenziale HTML che potrebbe essere immesso nel modulo.

Best practice:

• Lasciare che i flussi vengano eseguiti nel loro contesto predefinito a meno che non sia necessario elevare l'accesso dell'utente in esecuzione per un'operazione specifica.
• Evitare di eseguire flussi nel contesto di sistema per gli utenti guest per motivi di sicurezza. Creare invece insiemi di autorizzazioni con accesso limitato ai campi assegnati al profilo utente guest del sito Experience Cloud.
• Quando si eseguono query sui record nei flussi di sistema eseguiti dal contesto nei siti Experience Cloud, memorizzare solo i campi necessari nell'elemento Ottieni record o nelle azioni invocabili.
• Se un flusso esegue varie operazioni e non tutte richiedono un accesso elevato, utilizzare i sottoflussi per isolare le operazioni che devono essere eseguite nel contesto di sistema.
• Se si prevede di incorporare un modulo in una pagina Web esterna, valutare la possibilità di disinfettare gli input degli utenti per rimuovere l'HTML utilizzando un flusso di aggiornamento rapido dei campi o un trigger Apex se alla fine verranno mappati a campi di testo RTF per prevenire potenziali attacchi di phishing da parte di malintenzionati.

• OmniScript, FlexCard e LWC vengono eseguiti nel contesto dell'utente per impostazione predefinita.
• I componenti LWC vengono eseguiti nel contesto dell'utente per impostazione predefinita e i flussi nel contesto dell'utente, ma è possibile ignorarli in un controller Apex.
• Le operazioni eseguite tramite l'API dell'interfaccia utente vengono eseguite nel contesto dell'utente.
• Le operazioni eseguite tramite un controller Apex dipendono da quella classe. Per eseguire queste operazioni in modalità di sistema, impostare la classe Apex su con condivisione o senza condivisione.

Se è necessario controllare chi può accedere al modulo, è spesso possibile esaminare il contenitore in cui è incorporato il modulo. Ad esempio, è possibile assegnare pagine Lightning in modo che siano disponibili per applicazioni, tipi di record o profili specifici. Se alcuni input del modulo sono sensibili, utilizzare le regole di visibilità per controllare ulteriormente cosa viene visualizzato a chi; questa funzione si applica sia ai moduli dinamici che ai flussi schermata.

È possibile limitare un flusso a particolari profili o insiemi di autorizzazioni, esattamente come si può fare con una classe Apex o una pagina Visualforce. Per impostazione predefinita, i flussi non sono soggetti a restrizioni, il che significa che tutti gli utenti con l'autorizzazione utente Esegui flussi possono eseguirli.

Se si utilizza OmniStudio, è possibile configurare un controllo autorizzazioni classe Apex per assicurarsi che gli utenti richiedano un accesso esplicito alla classe Apex che amministra l'azione remota chiamata da un'API OmniScript, FlexCard, Classic Card o REST.

• Nota I controlli delle autorizzazioni delle classi Apex sono abilitati per impostazione predefinita per gli script appena creati. Tuttavia, devono essere abilitati manualmente per tutti gli script esistenti
• Tenere presente inoltre che i controlli delle autorizzazioni delle classi Apex si applicano solo alle classi Apex. Si consiglia di impostare le autorizzazioni a livello di profilo anche per Procedure di integrazione e Data Mappers.

Per ulteriori dettagli e procedure consigliate sulle autorizzazioni utente guest, vedere:

• Procedure consigliate per l'accesso record utente guest
• Sviluppo di siti sicuri: Utenti autenticati e guest

Best practice:

• Se si espone un flusso agli utenti guest, concedere al profilo utente guest l'accesso solo ai flussi di cui ha bisogno. Sebbene sia possibile aggiungere Esegui flussi al profilo utente guest, riteniamo che sia una procedura rischiosa.
• Prestare particolare attenzione ai flussi che operano nel contesto di sistema. Si consiglia vivamente di limitare tali flussi a un determinato gruppo di utenti, poiché dispongono di meno controlli e bilanciamenti per proteggere i dati.
• Assicurarsi che qualsiasi OmniScript che esegue Apex in una comunità di utenti guest abbia "con condivisione" nella definizione della classe Apex.
• Nel profilo Utente guest, assegnare solo le classi Apex che si desidera vengano chiamate dagli utenti guest, altrimenti si rischia di esporre involontariamente ulteriore logica aziendale agli utenti guest.

Per i componenti LWC, è possibile controllare le assegnazioni delle autorizzazioni dell'utente in esecuzione per verificare se dispone di una determinata autorizzazione standard o personalizzata. Direttamente da JavaScript, è possibile importare le autorizzazioni Salesforce dai moduli con ambito @salesforce/userPermission e @salesforce/customPermission. Oppure si può utilizzare Apex per controllare lo stesso.

I componenti Web Lightning sono disponibili in una determinata posizione solo quando sono stati aggiunti come destinazione valida. Ad esempio, è possibile rendere un componente disponibile nelle pagine dei record e non come elemento della barra delle utilità.

Una volta attivato, un flusso schermata è disponibile in tutte le posizioni in cui sono supportati i flussi schermata, indipendentemente dal fatto che sia disponibile ovunque. Detto questo, Flow Builder supporta più tipi di flussi con schermate. Il tipo pane e burro è Flusso schermata, ma esistono altri tipi specializzati limitati a posizioni specifiche. Ad esempio, l'app mobile Field Service supporta solo i flussi Field Service Mobile. Lo stesso vale per i flussi di richiesta di contatto, supportati solo in Experience Cloud.

Indipendentemente dal tipo di flusso, la persona che crea il flusso non ha alcun controllo sulla posizione in cui il flusso può essere incorporato. Il flusso sarà disponibile in tutte le posizioni supportate per quel tipo di flusso.

Se si utilizza Salesforce Industries, viene visualizzato un piccolo avvertimento quando si tratta di OmniScript: Benché non sia possibile specificare una destinazione per un OmniScript, è possibile specificarne una per le FlexCard che si desidera incorporarvi.

Le forme statiche appartengono al passato. Oggi, si tratta di aggiornare dinamicamente il modulo con le proprietà e i valori giusti per questo utente, questa volta, questo posto. Parliamo di ciò che è possibile fare in questo senso per gli strumenti di creazione di moduli di Salesforce.

• Quali tipi di interazioni o condizioni devono attivare risposte dinamiche all'interno del modulo?
• Sarà necessario eseguire operazioni fuori campo in background durante la compilazione del modulo?
• Sarà necessario impostare i campi come visibili, obbligatori, di sola lettura o disabilitati o modificare la formattazione in base agli input del modulo?

L'interattività dei flussi schermata è ora una realtà grazie alle schermate reattive. La reattività consente ai singoli componenti di una schermata del flusso di comunicare tra loro, rendendo i flussi schermata infinitamente più potenti.

Esegui operazioni sui dati fuori schermata: I flussi schermata offrono un approccio dichiarativo per recuperare i dati nella stessa schermata tramite Azioni schermata. Le azioni schermata possono consentire di attivare flussi AutoLaunched su qualsiasi modifica della schermata o quando un utente fa clic su un componente Pulsante di azione. È quindi possibile mappare i risultati di questi flussi AutoLaunched alla stessa schermata, eliminando la necessità per gli utenti di passare a un'altra schermata.

LWC offre una gamma completa di adattatori per cavi che consentono di accedere ai dati Salesforce per compilare dinamicamente i dati nei componenti del modulo e consente agli sviluppatori di aggiornare, eliminare e creare record tramite controller Apex.

Componenti Web Lightning Operazioni sui dati fuori schermoComponenti Web Lightning Operazioni sui dati fuori schermo __

Visibilità: La visibilità può essere controllata dinamicamente in tutti gli strumenti di creazione dei moduli. I moduli dinamici, Flow Builder e OmniStudio risolvono questo problema con le funzioni di visibilità dei componenti. In questo modo è possibile visualizzare o nascondere i campi in modo dichiarativo in base ad altri valori del modulo o indipendentemente dal fatto che l'utente si trovi su un dispositivo mobile.

• Con i moduli dinamici, la visibilità può essere controllata in base ai valori dei campi dei record, ai record correlati tramite campi di ricerca e al fattore di forma.
• Con Flusso, è possibile basare una regola di visibilità su altri input nella schermata, nonché su altre risorse compilate in precedenza nel flusso come formule o valori di altri record.
  • Regole basate sul dispositivo: Non è ovvio fin dall'inizio, ma è possibile utilizzare una formula per visualizzare o nascondere un particolare campo quando l'utente è su un dispositivo mobile. Scrivere una formula del flusso che controlli il valore della variabile globale $User.UIThemeDisplayed. Se il valore è Theme4t, l'utente si trova nell'app mobile Salesforce.
  • Valutazione di altre risorse: I riferimenti manuali alle variabili e alle formule vengono valutati solo sul server. Quindi, qualsiasi valore abbia quella risorsa quando la schermata viene visualizzata per la prima volta è il valore che avrà finché non si passa a un'altra schermata. Durante la navigazione, il runtime del flusso invia una richiesta al motore di flusso (il server) e recupera i valori più recenti delle variabili e delle formule manuali. Se si prevede che la regola di visibilità si aggiorni quando l'utente passa attraverso una singola schermata (ad esempio, onblur), assicurarsi di fare riferimento solo ai valori degli altri componenti della schermata.
• Con OmniStudio, è possibile visualizzare o nascondere i componenti in modo condizionale impostando una proprietà di visualizzazione condizionale. Tuttavia, non è possibile aggiungere più di una proprietà di visualizzazione condizionale per un input.

Stati di input condizionali: Se è necessario controllare dinamicamente altre proprietà, ad esempio se un campo è obbligatorio, disabilitato o di sola lettura, sono disponibili alcune opzioni. Come previsto, LWC offre un controllo completo e reattivo sullo stato di input. Con i componenti Flusso schermata reattivi, è possibile controllare dinamicamente attributi di componenti come Sola lettura, Disabilitato e Obbligatorio per i componenti standard che lo supportano, mentre OmniStudio supporta l'intera gamma di attributi specifici dei componenti. Se le proprie esigenze richiedono Flusso e il componente non supporta uno stato attributo specifico, è possibile creare un componente LWC incorporabile per ottenere uno stato di input dinamico.

Se è necessario controllare dinamicamente qualsiasi altra proprietà, ad esempio se un campo è obbligatorio o di sola lettura, la soluzione migliore a breve termine è LWC, in cui si ha il controllo completo. Ciò è particolarmente vero se sono presenti requisiti personalizzati per la gestione di onblur o onclick.

LWC reattivi nei flussi schermata: Quando si creano componenti LWC che possono sia reagire che modificare altri componenti in un flusso schermata, consultare questa guida alle procedure consigliate per i flussi schermata per assicurarsi che i componenti si integrino bene nel motore di runtime del flusso e funzionino come previsto in futuro.

Ora per gli eventi personalizzati. Se alcuni input o l'intero modulo devono comunicare con un'altra voce della pagina, LWC è l'unica opzione possibile.

• Per comunicare all'interno dello stesso albero DOM, utilizzare l'interfaccia CustomEvent.
• Per comunicare nel DOM, utilizzare Lightning Messaging Service.
• Se il servizio di messaggistica Lightning non è supportato per il contenitore di destinazione, utilizzare il modulo pub/sub.

• Per ulteriori dettagli, vedere Comunicazione con eventi e Comunicazione attraverso il DOM nella Guida Lightning Web Components Dev Guide.
• Per OmniStudio, consultare Comunicazione con OmniScript da un componente Web Lightning.

Per offrire la migliore esperienza utente è necessario assicurarsi che lo stile del modulo sia coerente con il resto dell'app o del sito in cui è incorporato. Raggiungere questo obiettivo può significare qualsiasi cosa, dall'utilizzo dei modelli standard forniti da Salesforce alla creazione di CSS personalizzati che utilizzano completamente ogni pixel nella progettazione per offrire un aspetto più nitido.

• Quanto sono sofisticati lo stile desiderato e CSS?
• Hai bisogno di uno stile personalizzato e pixel-perfetto o ti vanno bene i temi standard?

FlexCard è l'unico prodotto trattato in questa guida che consente di controllare in modo dichiarativo lo stile e il layout dell'interfaccia utente che si sta creando nello strumento direttamente, che si tratti di margini e imbottitura, tipografia, colori, ecc.

Sia i moduli dinamici che i flussi rispettano le funzioni dei temi dichiarativi. Se si necessita di un controllo che vada oltre il supporto dei temi Salesforce, dei set di immagini aziendali o dei siti Experience Cloud LWR, valutare la possibilità di utilizzare una soluzione a livello di programmazione.

Per i team che utilizzano CSS, sono disponibili due opzioni:

• I flussi e i componenti LWC ereditano i token di progettazione.
• OmniScript e FlexCard includono il supporto per un sistema di progettazione personalizzabile: Newport.
• Con LWC è possibile scrivere i propri componenti e controllare completamente HTML e CSS per essi.

Ove possibile, si consiglia di utilizzare temi e sistemi di progettazione, in modo che l'aspetto sia applicato in modo coerente a tutti i contenuti.

Promemoria: È possibile incorporare componenti Lightning nei flussi. Quindi, se è necessario un controllo pixel perfetto sull'aspetto della forma ma si desidera utilizzare gli altri vantaggi dei flussi, ad esempio il modello di navigazione, è possibile utilizzare il meglio di entrambi i mondi. Lo stesso principio vale per OmniScript e FlexCard.

La scelta di un buon layout è fondamentale per progettare moduli semplificati che consentano un'immissione rapida ed efficiente dei dati e aumentino l'integrità dei dati. Per ulteriori informazioni su questo argomento, vedere Salesforce Well-Architected - Forms.

• Come utilizzare il layout del modulo per ottimizzare le esperienze utente?
• Come si possono presentare i dati esistenti agli utenti in modo da semplificare l'immissione di nuovi dati nei moduli?

I moduli dinamici supportano i layout a due colonne e possono essere suddivisi in singole sezioni con campi. Queste sezioni possono essere inserite in componenti come schede e fisarmoniche per creare layout facili da usare e organizzati.

Se si desidera, il rendering dei flussi può essere eseguito utilizzando il componente Sezione. Con le sezioni è possibile aggiungere fino a quattro colonne e tutte le sezioni desiderate nella schermata del flusso. Il componente è anche reattivo alla larghezza dello schermo, quindi può funzionare su schermi più piccoli. Infine, consente di applicare la visibilità condizionale all'intera sezione, semplificando l'applicazione globale della visibilità a più campi all'interno della sezione. Le sezioni dei flussi supportano anche le intestazioni di colonna e offrono un'esperienza simile a una fisarmonica in cui gli utenti possono comprimere l'intera sezione facendo clic sull'etichetta.

Gli OmniScript offrono una varietà di opzioni di layout per la visualizzazione di campi e dati. È possibile creare sezioni di dati con un massimo di 12 colonne, incluse le fisarmoniche comprimibili in modo condizionale.

Con LWC, è possibile utilizzare Lightningrecord-[edit|view]-form e il campo Lightning[input|output]-supportato per controllare il layout. Le uniche limitazioni del layout sono quelle di HTML/CSS. Lightning-record-form rispetta la configurazione della sezione nel layout di pagina associato; ad esempio, se una sezione è a due colonne nel layout di pagina, è a due colonne in questo componente.

Se il modulo sarà accessibile da utenti di regioni diverse o che parlano lingue diverse, è necessario assicurarsi che lo strumento che si utilizzerà per crearlo soddisfi i requisiti di localizzazione. Vedere Salesforce Well-Architected - Localization per ulteriori indicazioni e consigli. Nel caso specifico dei moduli, i requisiti di localizzazione in genere includono la traduzione di elementi di testo in altre lingue.

• Il modulo verrà utilizzato in più di un paese o di una regione?
• Il testo nel modulo deve essere localizzato in altre lingue?

Se sono stati localizzati i campi personalizzati, le etichette tradotte vengono rispettate nei moduli dinamici. I moduli dinamici rispettano anche le etichette personalizzate assegnate alle etichette e agli attributi dei componenti nel Generatore di app Lightning.

Con la potenza dell'Area di lavoro traduzione, Flusso supporta la traduzione delle etichette rivolte agli utenti per tutti i componenti schermata standard e personalizzati. È possibile localizzare l'etichetta, il testo della guida e il messaggio di errore dei seguenti componenti schermata: Testo, Area di testo lungo, Numero, Valuta, Casella di controllo, Pulsanti di opzione, Elenco di selezione, Elenco di selezione a selezione multipla, Gruppo caselle di controllo, Password, Data e Data/ora.

Non è disponibile un supporto per la traduzione incorporato per le azioni pronte all'uso, ad esempio Invia email o Pubblica su Chatter. Tuttavia, c'è una soluzione! Se si definiscono le etichette tradotte con un'etichetta personalizzata, è possibile fare riferimento a tale etichetta personalizzata nell'azione o nel componente quando si configura in Flow Builder. Creare una formula del flusso che faccia riferimento all'etichetta personalizzata e fare riferimento a tale formula nelle posizioni appropriate del flusso.

Gli OmniScript utilizzano etichette personalizzate per le traduzioni. Fare riferimento a questo documento per preparare gli OmniScript multilingue.

Ora per LWC. Alcuni componenti di base ereditano automaticamente le traduzioni dei campi, del testo della guida e dei messaggi di convalida dell'oggetto associato se sono stati configurati nell'Area di lavoro traduzione (ad esempio Lightning-record-form).

Se è necessario introdurre nuove etichette traducibili nel codice, le etichette personalizzate sono ancora l'eroe non cantato. Dichiarare l'etichetta personalizzata necessaria e quindi importarla nel componente dal modulo @salesforce/label scoped.

Sono disponibili diversi strumenti di automazione dei test end-to-end (ad esempio, Selenium) che consentono di simulare come l'utente interagisce con il modulo. È possibile scrivere questi test per qualsiasi interfaccia utente standard o personalizzata, incluse le pagine Lightning e i flussi schermata. Tuttavia, è importante notare che questi tipi di test non possono verificare gli output di ogni metodo in esecuzione. Assicurarsi di tenerne conto quando si esaminano i requisiti per l'automazione dei test dell'interfaccia utente.

• Sono necessari test automatici per il modulo?
• Quali tipi di test è necessario eseguire?
• Quale livello di dettaglio è necessario nelle automazioni di test?

Considerare i propri requisiti per l'automazione dei test dell'interfaccia utente.

I test di unità consentono un'automazione e una convalida più granulari che funzionano con i sistemi e gli strumenti standard del settore per i CD/informatici, in grado di testare la logica aziendale dei componenti, il relativo controller JavaScript e i relativi output. Se si utilizza esclusivamente low-code non sarà possibile creare test autonomamente, ma Salesforce testa rigorosamente le nostre offerte end-to-end.

Se i metodi del componente sono abbastanza complessi da voler essere testati singolarmente, inserirli in file JavaScript dedicati. In questo modo è possibile importarli in un LWC e in un test Jest con qualcosa come import { sort } from 'c/utils';.

Vedere Automazione test interfaccia utente per un confronto delle varie opzioni disponibili per creare un'automazione end-to-end in Salesforce. Sono incluse considerazioni su quando utilizzare una soluzione senza codice da un ISV, Build Your Own soluzione di automazione dei test personalizzata o utilizzare un framework di test open source come Selenium WebDriver o WebdriverIO. Queste soluzioni sono valide per qualsiasi interazione dell'interfaccia utente in Salesforce, sia che si tratti di un modulo dinamico in una pagina Lightning, di un flusso schermata in una barra delle utilità o di un LWC in un flusso in un'azione.

Dopo aver distribuito il modulo in un ambiente di produzione, è consigliabile assicurarsi che venga utilizzato in modo efficace. A seconda del caso d'uso, questo può significare qualsiasi cosa, dal semplice tracciamento del numero di volte in cui è stato compilato alla quantità di tempo che gli utenti trascorrono compilandolo prima di inviare le loro informazioni. Assicurarsi di identificare i KPI di cui si desidera tenere traccia prima di scegliere uno strumento.

• È necessario tenere traccia dell'utilizzo del modulo?
• Quali KPI determinano se il modulo viene utilizzato in modo efficace?

Se è necessario tenere traccia dell'utilizzo complessivo e dell'adozione del modulo, iniziare con gli strumenti low-code. Sia i moduli dinamici che i flussi schermata sono tracciabili utilizzando tipi di rapporti personalizzati pronti all'uso, anche se i rapporti di tracciamento dei flussi schermata offrono una maggiore chiarezza. Se è necessario tenere traccia dell'utilizzo di un LWC, la disponibilità pronta all'uso dipende da dove si utilizza quel LWC. Se si trova in una pagina Lightning, qualsiasi elemento disponibile per il tracciamento dell'utilizzo delle pagine Lightning si applica al componente LWC. Lo stesso vale per i componenti LWC incorporati nei flussi.

I moduli dinamici non sono tracciabili immediatamente, anche se è possibile tenere traccia dell'utilizzo della pagina Lightning controllante tramite gli oggetti Utilizzo Lightning. Per tenere traccia delle pagine Lightning standard, utilizzare il tipo di rapporto personalizzato Utenti con Lightning Usage by Page Metrics. Per lo stesso motivo nelle pagine Lightning personalizzate, utilizzare il tipo di rapporto personalizzato Utenti con utilizzo Lightning per metriche FlexiPage.

Per tenere traccia dell'adozione del modulo specifico (non solo della pagina in cui si trova), Flusso offre una copertura completa. Utilizzare il "Rapporto flusso di esempio: Screen Flows" per rispondere a domande come:

• Qual è la percentuale di completamento di questo modulo? È stato adottato bene?
• Quanto tempo impiegano gli utenti a compilare questo modulo?
• Su quale schermata gli utenti trascorrono più tempo?
• Con che frequenza gli utenti navigano all'indietro?
• Con che frequenza si verificano gli errori?

Se il rapporto standard non soddisfa le proprie esigenze, clonarlo per apportare le proprie modifiche o Build Your Own da zero utilizzando il tipo di rapporto Flussi schermata.

Se si utilizza il runtime OmniScript basato su pacchetto, è possibile utilizzare OmniStudio per Vlocity Tracking Service. Questo servizio tiene traccia di qualsiasi tipo di evento. Ad esempio, è possibile tenere traccia del tempo necessario per completare i passaggi di un OmniScript per identificare i miglioramenti del processo. La roadmap del team OmniStudio prevede il supporto di questo servizio in OmniStudio standard.

Per tenere traccia dello stesso per un LWC non incorporato in un flusso schermata, OmniScript o pagina Lightning, non è disponibile un'opzione pronta all'uso. È possibile creare una soluzione personalizzata utilizzando Apex.

Quando è necessario distribuire la soluzione in ambienti superiori per il test o la distribuzione in produzione, è possibile che si sia abituati a utilizzare le serie di modifiche o DevOps Center per farlo. I moduli dinamici, i flussi e i componenti LWC sono completamente supportati in queste opzioni di distribuzione. OmniStudio richiede uno strumento separato: Area di lavoro IDX.

• Come si prevede di distribuire il modulo?
• Il modulo verrà distribuito a più di un'organizzazione Salesforce?

Se si è un ISV o un partner che prevede di inserire la soluzione in un pacchetto per la distribuzione su AppExchange, si consiglia di esaminare prima i moduli dinamici, i flussi e i componenti LWC. OmniStudio non supporta i pacchetti.

Questa guida si concentra sull'aiutare a capire quali funzionalità e livelli di personalizzazione sono possibili con moduli dinamici, flussi schermata, OmniStudio e LWC. Ad un livello elevato:

• LWC è l'opzione più personalizzabile e robusta per la creazione di un modulo, ma ha il minor numero di guardrail. Spetta all'utente creare un componente in modo da garantire la sicurezza e la scalabilità.
• I moduli dinamici sono i meno flessibili, ma le opportunità di errore sono molto meno numerose.
• Flusso e OmniStudio si trovano da qualche parte nel mezzo, più potenti dei moduli dinamici ma non proprio al livello di LWC. Allo stesso modo, hanno meno guardrail rispetto ai moduli dinamici ma sono più difficili da violare rispetto al codice personalizzato.

Se più strumenti sono adatti alla fattura, la decisione dipende da quale strumento è quello giusto per il team. Altre Guide alle decisioni introducono ulteriori aspetti da considerare quando si prende quella decisione.

Non entreremo qui nei dettagli di ciascuno di questi aspetti, ma quello che faremo è interpretarli per gli strumenti specifici che questo documento sta valutando.

Competenze specializzate: Quanta esperienza ha il team negli strumenti che si confrontano? Quanti produttori sono esperti e hanno familiarità con LWC o JavaScript? Che ne dici dei produttori esperti in Flow Builder o che hanno espresso interesse a immergere le dita dei piedi? In generale, le competenze relative a moduli dinamici e flussi sono più accessibili per una popolazione più ampia di persone che creano moduli. I moduli dinamici sono lo strumento più dichiarativo per la creazione di moduli e saranno sempre più facili da imparare rispetto al flusso. Detto questo, il team del flusso si impegna a ridurre al minimo la barra. In termini di complessità, OmniStudio si trova a metà strada tra Flusso e LWC e offre notevoli poteri di creazione della forma.

Delega di consegna: Solo perché alcuni requisiti richiedono LWC, non significa che l'intera soluzione debba essere creata con LWC. Considerare come creare la soluzione in modo modulare, in modo che le parti che richiedono LWC siano codificate e quelle che non lo richiedono siano in una soluzione low-code. In questo modo si massimizza l'efficienza di un team diversificato e si garantisce che ogni persona stia risolvendo i problemi appropriati per la propria specializzazione.

Parliamo ora di Flusso e LWC. Con i componenti schermata reattivi, i componenti del flusso schermata possono ora comunicare tra loro sulla stessa schermata sbloccando una nuova cassetta degli strumenti per architetti, amministratori e sviluppatori. Gli sviluppatori possono ora creare componenti modulari mirati che possono essere riutilizzati in tutta l'organizzazione, aumentando la produttività per tutti i membri del team. Gli sviluppatori possono concentrarsi sulla risoluzione di nuove sfide e risparmiare tempo utilizzando un mix di componenti Flusso standard e personalizzati per ottenere dinamismo della forma. Con i componenti reattivi in Flusso, non c'è mai stato un momento più appropriato per combinare Flusso e LWC durante la creazione dei moduli.

Gestibilità e proprietà a lungo termine: Se si dispone di un modulo a più fasi, è consigliabile iniziare con Flusso o un mix di Flusso e LWC. Se è presente un team low-code che gestisce la soluzione, pensare a come rendere la soluzione il più configurabile e ampliabile possibile per quel pubblico. Qualunque sia lo strumento scelto, organizzare la soluzione in unità componibili per migliorare la manutenibilità e la stabilità.

In futuro, il modo consigliato per configurare le pagine dei dettagli dei record è Moduli dinamici nel Generatore di app Lightning utilizzando le pagine Lightning. È passato molto tempo da quando abbiamo ottimizzato i layout di pagina e questa tendenza continuerà. Ecco perché:

• I moduli dinamici sono più flessibili: è possibile posizionare campi e sezioni dove si desidera direttamente nel Generatore di app Lightning, dove è possibile utilizzare sezioni, schede e fisarmoniche. E proprio come si può fare con i componenti nella pagina Lightning, è possibile controllare la visibilità dei campi e delle sezioni senza definire più layout di pagina o tipi di record.
• Con i componenti Fisarmonica e Scheda è possibile limitare la quantità di campi visualizzati inizialmente. Indovina cosa significa? Tempi di caricamento delle pagine più rapidi.
• La gestione dei layout è più semplice con le pagine Lightning, poiché è possibile gestire tutto ciò che riguarda le pagine dal Generatore di app Lightning, sia che si tratti dei contenuti della pagina o degli utenti che hanno accesso alla pagina. Non è più necessario eseguire aggiornamenti nel layout di pagina per apportare una modifica nella pagina Lightning. Per non parlare del fatto che, grazie alle potenti regole di visibilità, non è più necessario creare più pagine (o layout di pagina) per controllare chi vede quali campi quando. Ciò significa anche che è sufficiente assegnare agli utenti una pagina Lightning anziché assegnare sia una pagina Lightning che un layout di pagina.

Si consiglia di utilizzare i moduli dinamici dove possibile e di tornare ai layout di pagina solo quando necessario. Come sempre, accogliamo con favore il feedback nello scambio di idee sui miglioramenti che avrebbero maggior impatto sulla vostra organizzazione.

Tutte le considerazioni sulle prestazioni relative a moduli dinamici, flussi schermata, OmniStudio e LWC si basano sul framework in cui si trovano le tecnologie. Quelli basati su LWC (oltre, ovviamente, a un LWC) supereranno quelli basati su Aura. Il framework LWC offre prestazioni migliori perché le funzionalità principali sono implementate in modo nativo nei motori Web anziché in JavaScript tramite astrazioni del framework. Se non si ha dimestichezza, leggere questo post.

Nel 2019 abbiamo condotto un caso di studio confrontando le prestazioni delle stesse funzionalità in Aura e in LWC. Con la conversione di DreamHouse da Aura a LWC, non solo l'esperienza di sviluppo è stata molto più allineata agli attuali standard e schemi di sviluppo front-end Web, ma i miglioramenti delle prestazioni sono stati significativi. Le misurazioni di laboratorio hanno mostrato guadagni nell'intervallo dal 2,4% al 24,7% per la cache fredda e guadagni nell'intervallo dal 31,83% al 63,32% per la cache calda sulle stesse due pagine.

Ora, quale framework stanno utilizzando le nostre tecnologie dei moduli? In altre parole, quali tecnologie di forma traggono vantaggio da queste prestazioni superiori?

• I moduli dinamici, integrati nei metadati delle pagine Lightning, sono basati sullo stack LWC, che ci consentirà di implementare alcune funzionalità richieste da tempo. Come bonus di prestazioni, i moduli dinamici utilizzano il rendering progressivo, che si traduce in un tempo di caricamento delle pagine migliorato per le pagine con un numero elevato di campi.
• I flussi schermata sono basati su LWC, con la maggior parte dei singoli componenti pronti all'uso ora convertiti in LWC, ad eccezione di due componenti pronti all'uso: Caricamento file e immagine. Anche se il team Flusso ha convertito il client di runtime del flusso in LWC e la maggior parte dei suoi componenti, i clienti devono comunque convertire i componenti schermata Aura in LWC. Non solo, ma Salesforce supporta solo i componenti LWC nel nuovo framework dei componenti reattivi nei flussi schermata. C'è un ottimo modulo Trailhead che spiega come farlo: Componenti Web Lightning per sviluppatori Aura. Va da sé: Se si sta pensando di creare un componente personalizzato per un flusso schermata o qualsiasi altro contenitore, passare sempre a LWC.
• Sono disponibili alcune versioni di OmniStudio. Se si è un cliente di lunga data, è possibile che si utilizzi Angular. Invitiamo tutti i nuovi clienti a iniziare con OmniScript e FlexCard basati su LWC e a migrare i clienti esistenti da Angular.
• LWC è costruito su ... LWC ovviamente. Questo è un omaggio. 🤓

In qualità di architetto, è importante avere una solida conoscenza di tutte le opzioni disponibili e di come applicarle nel proprio caso d'uso specifico. Per la creazione di moduli in Salesforce, le opzioni variano da low-code (utilizzando moduli dinamici nel Generatore di app Lightning, flussi schermata in Flow Builder e OmniScript in OmniStudio) a pro-code (utilizzando il framework LWC), con una combinazione di flussi schermata o OmniScript e LWC nel mezzo. Tenere presente questa guida e utilizzarla come riferimento quando si prevede di creare o riprogettare i moduli in Salesforce. Per istruzioni su come progettare moduli semplificati e utili, consultare Salesforce Well-Architected: Coinvolgente.

Aiutaci a pubblicare ciò che è più rilevante per te: partecipa al sondaggio per fornire un feedback su questo contenuto e dicci cosa vorresti vedere dopo.