Creazione di moduli

Esistono diverse opzioni per la creazione di moduli in Agentforce 360 Platform e si estendono in un continuum che va dagli approcci low-code a quelli pro-code. Su un'estremità del continuum, i moduli dinamici nel Generatore di app Lightning e i flussi schermata in Flow Builder possono essere utilizzati per le soluzioni low-code. Dall'altro lato, il framework Lightning Web Component (LWC) viene utilizzato per le soluzioni pro-code. All'interno del continuum, gli strumenti possono essere combinati in diversi modi utilizzando flussi schermata estesi da LWC e moduli indirizzati ai clienti creati utilizzando OmniStudio.

Questa guida presenta un framework decisionale e indicazioni sulla creazione di moduli per le soluzioni dell'interfaccia utente. Nello specifico, utilizza una dozzina di punti di esecuzione e di decisione non funzionali per selezionare correttamente la tecnologia migliore per un determinato caso d'uso.

• Quando si creano/modificano/visualizzano layout per le pagine Lightning, utilizzare i moduli dinamici. In futuro, si consiglia di utilizzare i moduli dinamici nel Generatore di app Lightning per configurare le pagine dei dettagli dei record.

• Se è necessario creare, creare o modificare un modulo per un oggetto, utilizzare Pagine Lightning e Moduli dinamici. Questo è il modo più semplice per creare moduli in Agentforce 360 Platform. Fornisce anche funzionalità aggiuntive (ad esempio, il controllo della visibilità dei campi).

• Se si crea un modulo multipagina o una procedura guidata e non si hanno requisiti rigorosi per l'utilizzo dell'interfaccia utente o dell'immagine aziendale, utilizzare un flusso schermata. I flussi schermata offrono un framework di navigazione lineare per l'orchestrazione di più moduli. È possibile utilizzare i componenti LWC per creare il proprio framework per spostarsi tra i moduli, ma si consiglia di lasciare che sia il flusso a eseguire il lavoro in modo da potersi concentrare sui moduli stessi anziché sullo stato del modulo.

• Se sono necessarie logiche o azioni aggiuntive per supportare il modulo, utilizzare un flusso schermata, OmniStudio o LWC. Ciascuno di questi strumenti offre diversi modi per migliorare la soluzione consentendole di espandersi oltre la creazione o la modifica di un singolo record. In questo caso, il termine più può riferirsi a una logica avanzata (ad esempio, ramificazione o iterazione) o ad azioni come l'integrazione con sistemi esterni, l'invio di email o l'invio di notifiche push all'app mobile di un utente.

• Se sono presenti requisiti UX sofisticati o se è necessario gestire dinamicamente più della visibilità dell'interfaccia utente, utilizzare LWC o OmniScript. Per i requisiti che possono essere soddisfatti utilizzando i layout a tema e basati su colonne, è possibile creare i moduli direttamente in un generatore di codice basso. Tuttavia, il controllo granulare sullo stile della forma richiede la 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 consente di creare moduli consumer in grado di gestire logiche aziendali complesse e trasformazioni dei dati.

• Se è necessario distribuire l'automazione dei test, utilizzare LWC. È possibile scrivere test di unità per qualsiasi LWC, indipendentemente da dove viene incorporato. Ciò consente di creare una strategia di test più efficace, che può includere test in blocco con più record e test negativi.

• L'utente non è vincolato da decisioni "né dall'una né dall'altra". È possibile combinare più opzioni per ottenere la soluzione migliore per i propri casi d'uso (ad esempio, se è necessario il sistema di navigazione integrato di Flow e la completa flessibilità di stile offerta da LWC, è possibile utilizzarli insieme).

Per implementare ed estendere le esperienze dei moduli vengono comunemente utilizzati i seguenti strumenti.

Questa tabella descrive gli strumenti disponibili per la creazione di moduli tramite Salesforce, insieme alle competenze richieste e alle considerazioni sulla licenza.

Nota: Approfondiremo le funzioni specifiche supportate per ogni strumento, come scegliere tra strumenti basati su clic e strumenti basati su codice e quando combinarli in una sezione successiva.

Quando si selezionano prodotti e strumenti, è necessario tenere presenti diversi punti di decisione. Questa tabella delinea diversi punti decisionali e fornisce indicazioni generali.

Nota: Nelle tabelle di confronto decisioni successive sono presenti alcuni valori associati a qualsiasi coppia strumento-funzione:

• Disponibile: Lo strumento/la funzione funziona con le considerazioni di base.

• Non disponibile: Non è previsto alcun aumento del supporto entro i prossimi dodici mesi.

• Non ideale: Questo strumento/funzionalità può funzionare, ma non è lo strumento ottimale.

• Non applicabile: Lo strumento non si applica al caso d'uso specifico.

Utilizzare questi scenari per confrontare le scelte relative agli utensili in base all'ambito, all'esperienza utente e alle esigenze operative.

Se è possibile ottenere tutti gli input utente da un modulo a schermata singola, iniziare con i moduli dinamici. Tenere presente che i moduli dinamici nelle pagine dei record possono utilizzare la funzione Percorso per supportare i processi aziendali in più fasi.

• È necessaria una schermata singola o l'utente dovrà spostarsi tra più schermate per completare un'operazione?

• Si desidera che gli utenti visualizzino lo 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à di quelle offerte dai moduli dinamici, la scelta tra Flusso, Omnistudio e LWC dipende da alcune domande aggiuntive:

• È possibile visualizzare una barra di navigazione in fondo al modulo? Se l'esperienza di navigazione Flusso schermata e OmniScript fornisce un'interfaccia utente indesiderata, propendere per LWC.

• Che cosa deve accadere dietro il modulo? Se è necessario che il comportamento sia configurabile da un amministratore, utilizzare un flusso. Per relazioni complesse tra più oggetti, utilizzare OmniScript o LWC.

Se si sceglie Flusso o OmniStudio, potrebbe anche essere necessario creare 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 è necessario incorporare quel componente in un flusso.

Navigazione guidata

D'altra parte, se la soluzione ha l'aspetto di 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 incorporato, 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.

Omnistudio offre un vantaggio di navigazione chiave fornendo indicatori di avanzamento dalla navigazione standard che evidenziano le fasi all'interno del modulo. La visualizzazione fase visualizza automaticamente la posizione di un utente in un modulo a più fasi. A differenza di Flusso, consente agli utenti di passare da una schermata all'altra facendo clic su varie fasi del modulo.

Sia che si creino moduli a schermata singola che a schermata multipla, è importante assicurarsi che i moduli siano semplificati 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; tuttavia, i moduli dinamici sono attualmente disponibili solo sul desktop. 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 abilitare le azioni in modo che gli utenti possano compilare il modulo senza dover uscire dalla pagina in cui si trovano attualmente?

• Il modulo deve essere disponibile su un sito Web esterno?

Poiché richiede contesto record, la funzione Moduli dinamici è supportata solo nelle pagine di record Lightning. Tuttavia, i moduli dinamici non sono supportati nelle pagine Experience Cloud.

È possibile creare flussi che richiedono un contesto record o flussi che funzionano a livello globale. In altre parole, è possibile incorporare i flussi in una varietà di posizioni. Per i flussi contestuali a record, le posizioni possono includere: Pagine di record Lightning, pagine di record Experience Cloud, azioni specifiche di un oggetto o distribuzioni di azioni e consigli. Per i flussi globali, le posizioni possono includere: la barra delle utilità, altre pagine Lightning o Generatore di esperienze, Snap o applicazioni esterne. Attualmente, i flussi non sono supportati come azioni globali, ma è possibile racchiudere i flussi in un componente Aura come soluzione.

OmniStudio consente di creare FlexCard e OmniScript componibili che possono essere posizionati quasi ovunque sia possibile inserire un flusso, ma anche se sono componibili, non sono inseribili in pacchetti.

LWC offre un elevato grado di riutilizzo per la creazione di componenti che possono essere associati ai target tramite metadati in Salesforce, comunità e progetti open source. I componenti LWC possono anche essere incorporati nel proprio sito Web utilizzando Lightning Out 2.0.

I componenti LWC possono anche avviare i flussi con il componente Lightning-Flow.

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

Attualmente, nessuna delle tecnologie dei moduli trattate in questa guida è ufficialmente supportata nei modelli Mobile SDK. Se Mobile SDK è essenziale per il proprio caso d'uso, si consiglia di creare il modulo in modo nativo nell'applicazione mobile o di creare una pagina Visualforce, pur tenendo presente il fattore di forma.

I moduli dinamici sono perfetti se è necessario utilizzare i valori del modulo per creare o aggiornare un record. Sarà necessario sfruttare Flusso, OmniStudio o LWC per funzionalità esterne a tale ambito, ad esempio la creazione di livelli decisionali o di iterazione o la generazione di post o email Slack utilizzando gli input del modulo.

• Quali azioni o logica è necessario eseguire dietro le quinte?

• È necessario utilizzare i valori di un record correlato?

• 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 e non è necessario scrivere codice per nessuna di queste operazioni. LWC offre interazioni complete con singoli record e oggetti correlati tramite adattatori che interagiscono con l'API interfaccia utente. LWC può anche interagire con più record utilizzando il wire per getListInfoByName.

Omnistudio utilizza procedure di integrazione e Data Mapper per ottenere e trasformare i dati (sia esterni che interni a Salesforce). Grazie alle numerose funzioni senza codice, eccelle nell'appiattimento e nell'espansione delle serie di dati con vari livelli di relazioni.

Flusso, OmniStudio e LWC si integrano tutti con Apex, quindi è possibile chiudere facilmente eventuali lacune all'interno della soluzione scelta (ad esempio, se è necessario filtrare i record da un LWC, è possibile utilizzare l'adattatore per fili Apex per creare query SOQL complesse. Se si è influenzati dalle storie basate sui clic, valutare la possibilità di utilizzare Flusso o OmniStudio come valida alternativa a un controller Apex per le proprie esigenze lato server.

È anche opportuno valutare se si desidera confermare immediatamente le azioni o rinviarle a una particolare parte del modulo. Questo è particolarmente rilevante se si utilizza un modulo a più pagine. Il flusso consente di combinare facilmente gli input di più moduli (schermate del flusso) e di utilizzarli in seguito nella procedura guidata (flusso) per eseguire determinate operazioni, che è esattamente il modo in cui si consiglia di progettare i flussi. Eseguire azioni alla fine (nel caso in cui gli utenti rimbalzino avanti e indietro tra le schermate per modificare le risposte).

Le transazioni e i limiti del governatore sono parte integrante di Agentforce 360 Platform. Se il caso d'uso è abbastanza semplice, potrebbe non essere altrettanto importante controllare la transazione in cui 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.

Ecco alcuni esempi:

• Ritiro: Si supponga che il modulo crei più record in background. Se la creazione di un terzo record non riesce, i primi due record devono essere ritirati? Se ogni azione è indipendente l'una dall'altra, è possibile eseguirla come transazione separata. Tuttavia, se sono dipendenti l'una dall'altra e si desidera che il fallimento di una faccia retrocedere anche le altre, è necessario implementarle come singola transazione. Se il modulo è in Flusso, è possibile utilizzare l'elemento Rollback nel percorso di errore per ritirare la transazione e garantire l'integrità dei dati.

• Impatto a valle sui limiti del governor: Quando il modulo crea o aggiorna un record, è importante considerare 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 possono essere attivati in base alle modifiche dei record proposte?

  • In che modo queste modifiche collettive influiscono sui limiti del governor utilizzati all'interno di quella transazione?

  • Se una particolare modifica del record può comportare molte modifiche a valle che influiscono sui limiti, può essere consigliabile isolare la modifica del record all'interno della propria transazione.

• Elaborazione batch: Può essere necessario raggruppare in batch più aggiornamenti insieme (anche all'interno di un contesto dell'interfaccia utente). 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 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 si verifica all'interno di 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 di input all'API.

3. L'API riceve la richiesta e apre una transazione e una connessione al database. Quindi, l'API chiama 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 viene visualizzata una schermata o un nodo di azione locale. Quindi, il motore restituisce 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 (in base all'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 interagisce.

7. Iniziare dal punto 1 e ripetere il processo.

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 inizia una nuova transazione. Tenere presente che gli elementi di progettazione specifici (le operazioni che si raggruppano in una determinata transazione) dipendono dall'utente.

Ecco alcuni esempi:

• All'inizio, verrà visualizzato un flusso che raccoglie gli input in più schermate ed esegue diverse azioni all'interno di una sola transazione.
• Il flusso successivo esegue ogni operazione in una transazione separata.
• I flussi possono anche utilizzare i record di ritiro per consentire di ritirare un'intera transazione se una singola operazione non riesce in una serie di operazioni del database. Si supponga di avere un flusso che crea record, aggiorna record e quindi crea record aggiuntivi (illustrati nel flusso successivo).

In questo scenario, se i primi due elementi hanno esito positivo e l'ultimo ha esito negativo, le prime due operazioni DML creano e aggiornano comunque i record appropriati, ma il terzo non lo farà. Utilizzando l'elemento Ritiro record, è possibile assicurarsi che l'intera transazione venga ritirata se tutte e tre le operazioni devono avvenire collettivamente (come indicato nel flusso finale).

Nota: Per ulteriori informazioni, vedere Flussi nelle transazioni e Bulkificazione dei flussi.

La possibilità di controllare la transazione da un LWC si basa sui 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) si verifica all'interno di una transazione indipendente quando viene inviato il modulo.

In generale, valgono le seguenti regole:

• Ogni chiamata API dell'interfaccia utente è isolata all'interno della 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). Tenere presente che le normali regole di transazione per quella tecnologia rimangono valide.

Flusso, OmniStudio e LWC supportano tutti gli eventi piattaforma (per l'architettura basata sugli eventi) e le integrazioni API. Oltre all'Apex Code personalizzato, Flow e Omnistudio dispongono di meccanismi di supporto dichiarativi che possono essere integrati anche con le API.

Se è necessario connettersi a un'API MuleSoft o a un bot RPA, utilizzare i servizi MuleSoft, poiché in questo modo viene generato un servizio esterno.

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

Per tutte le altre istanze, utilizzare la funzione di chiamata HTTP (generata da Servizi esterni) nel flusso o l'azione HTTP in Omnistudio.

Omnistudio dispone di una serie completa di funzionalità di integrazione che possono effettuare chiamate a sistemi esterni utilizzando procedure di integrazione per trasformare i dati tramite Data Mapper.

Indipendentemente dal fatto che si utilizzi Apex Code personalizzato o un servizio esterno per l'implementazione, una chiamata è comunque una chiamata.

Ecco cosa devi sapere.

• L'elaborazione di una chiamata può richiedere molto tempo.

• Quando una chiamata viene eseguita in modo sincrono, viene eseguita mentre è aperta una transazione del database.

• Salesforce non consente di mantenere aperta una transazione del database se sono presenti operazioni del database in sospeso.

Tenere presente che la limitazione principale è il pericolo di lasciare i dati in uno stato incoerente, che si verifica quando si esegue un'operazione di creazione, aggiornamento o eliminazione e quindi si esegue una chiamata all'interno della stessa transazione. Questo schema non è consentito a causa della terza considerazione di cui sopra, che esiste a causa delle prime due considerazioni.

In Flusso, è possibile ignorare questa limitazione interrompendo la transazione. Ricordare che le schermate e le azioni locali reintroducono il contesto del browser. Sebbene sia possibile utilizzare schermate e azioni locali quando si utilizzano chiamate esterne, si consiglia di abilitare Controllo transazioni nelle impostazioni avanzate invocabili. Controllo transazione consente di terminare automaticamente la transazione prima di effettuare una chiamata. Per abilitare Controllo transazione, selezionare "Inizia sempre una nuova transazione" nella sezione Avanzate dell'azione richiamata. LWC consente di semplificare l'impatto delle chiamate sulla transazione. In altre parole, eseguire le operazioni sui dati utilizzando Lightning Data Service (LDS) e quindi utilizzare un controller Apex per effettuare la chiamata esterna. Poiché la chiamata LDS è isolata all'interno della propria transazione (separata dalla chiamata Apex), ciò protegge l'utente da eventuali incoerenze dei dati risultanti.

I moduli dinamici non supportano il riutilizzo. Ogni pagina è collegata a una pagina di record Lightning specifica per un oggetto specifico; tuttavia, è possibile assegnare quella pagina di record Lightning a più app, profili e così via.

Analogamente a come si possono scrivere librerie, utilità e componenti che possono essere utilizzati in più componenti, è anche possibile applicare schemi di progettazione simili durante la creazione dei flussi sfruttando la potenza dei sottoflussi. A questo scopo, salvare i flussi in bucket modulari più piccoli e quindi chiamarli da altri flussi utilizzando l'elemento Sottoflusso. Se la progettazione lo richiede, è possibile creare un flusso utile da solo e come sottoflusso.

OmniStudio è intrinsecamente costruito per la modularità. Mappatori di dati, OmniScript, FlexCard e Procedure di integrazione sono tutti creati in modo indipendente, ma possono anche funzionare in modo intercambiabile. Le FlexCard possono anche 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 anche vantaggi di adattabilità e stabilità.

Tutte le tecnologie utilizzate per creare o aggiornare i record devono rispettare la convalida a livello di sistema, che si tratti di regole di convalida classiche o di convalide personalizzate incorporate in un trigger Apex. Indipendentemente dalla tecnologia utilizzata per eseguire le modifiche dei record, ogni modifica deve passare attraverso l'ordine di salvataggio. Ciò significa che oltre alle regole di convalida, le modifiche dei record vengono elaborate anche da un certo numero di flussi prima o dopo il salvataggio, trigger prima o dopo l'attivazione, regole di inoltro al livello superiore, regole di assegnazione e così via.

Nota: Se non lo si è già fatto, rivedere e inserire nei segnalibri l'ordine di esecuzione Apex.

• Il modulo ha altri requisiti oltre alla convalida a livello di sistema?

• È necessario impostare i campi obbligatori o di sola lettura in modo dinamico all'interno del modulo?

In genere, gli input in una schermata del flusso o in una fase OmniScript non sono vincolati, quindi il modulo stesso non aderisce in modo nativo alla convalida a livello di sistema associata a un particolare oggetto. Tuttavia, i valori utilizzati per creare o aggiornare i record vengono elaborati nell'ordine di salvataggio, ovvero passano attraverso la convalida a livello di sistema dell'oggetto.

Nota: Non tutti i componenti Flusso schermata supportano la convalida degli input.

Analogamente ai layout di pagina, i moduli dinamici consentono di impostare lo stato obbligatorio e di sola lettura a livello di pagina. Tenere presente che non è possibile ignorare le impostazioni a livello di sistema.

Il flusso offre flessibilità per la personalizzazione della convalida dell'input del modulo. Vengono eseguiti più controlli a livello di client (ad esempio, la segnalazione di campi obbligatori mancanti e controlli dei tipi di dati, nonché formule compatibili all'interno delle regole di convalida degli input). Come ulteriore livello di sicurezza, la convalida degli input viene valutata anche sul server. Quando un utente fa clic su Avanti, Flusso invia nuovamente gli input al server per la convalida. Se vengono restituiti input non validi, la navigazione viene bloccata e viene visualizzato l'errore appropriato.

Il server convalida gli input controllando:

• L'impostazione dell'obbligatorietà dell'input o se il valore immesso è compatibile con il tipo di dati sottostante.

• Convalida personalizzata dell'input. È necessario specificare un'espressione di formula booleana e un messaggio di errore da visualizzare quando l'espressione di formula non viene soddisfatta.

• Convalida personalizzata del componente sottostante. Se si crea un LWC personalizzato per un flusso, è necessario aggiungere il proprio codice di convalida al metodo validate().

È anche possibile fornire avvisi utente accessibili tramite il componente Messaggio in Flussi schermata, ma questo non impedisce a un utente di passare ad altre pagine o di passare alla fase successiva in un flusso guidato. Lo stato Errore all'interno del componente Messaggio è utilizzato al meglio nelle schermate di errore dedicate che vengono attivate tramite un percorso di errore quando la navigazione è disabilitata.

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

Per 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.

Tenere presente che i campi che richiedono l'inserimento di dati da parte degli utenti devono essere visualizzati all'inizio dei moduli. Convalidare gli input degli utenti sul lato client prima di inviare i moduli (quando possibile).

I moduli statici sono superati. Oggi, l'attenzione si è spostata sull'aggiornamento dinamico dei moduli con le proprietà e i valori appropriati per un utente specifico, in un momento specifico, in un luogo specifico. Vediamo più nel dettaglio cosa è possibile fare con gli strumenti di creazione di moduli Salesforce.

• Quali tipi di interazioni o condizioni devono attivare risposte dinamiche all'interno del modulo?

• È necessario eseguire operazioni fuori campo (in background) durante la compilazione del modulo?

• È necessario impostare i campi come visibili, obbligatori, di sola lettura o disabilitati oppure modificare la formattazione in base agli input dei moduli?

Le schermate reattive abilitano l'interattività del flusso schermata. La reattività consente ai singoli componenti di una schermata del flusso di comunicare tra loro, rendendo i flussi schermata più potenti.

Esecuzione di 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 consentono di attivare flussi AutoLaunched su qualsiasi modifica all'interno della schermata o quando un utente fa clic su un componente Pulsante di azione. È possibile mappare i risultati dei flussi AutoLaunched alla stessa schermata, eliminando la necessità per gli utenti di passare a un'altra schermata.

LWC fornisce una gamma completa di adattatori che forniscono l'accesso ai dati Salesforce per compilare dinamicamente i dati nei componenti modulo, il che consente agli sviluppatori di aggiornare, eliminare e creare record tramite controller Apex.

Visibilità

La visibilità può essere controllata dinamicamente in tutti gli strumenti di creazione di moduli. I moduli dinamici, Flow Builder e Omnistudio risolvono questo problema utilizzando le funzioni di visibilità dei componenti. È possibile visualizzare o nascondere i campi in modo dichiarativo in base ad altri valori all'interno del modulo o se l'utente sta compilando il modulo su un dispositivo mobile.

• I moduli dinamici controllano la visibilità in base ai valori dei campi dei record, ai campi di ricerca e al fattore di forma.

• Con Flusso, è possibile basare una regola di visibilità su altri input schermata, nonché su altre risorse compilate in precedenza nel flusso (ad esempio, formule o valori di altri record).

  • Regole basate sul dispositivo: Può non essere ovvio fin dall'inizio, ma è possibile utilizzare una formula per visualizzare o nascondere un particolare campo quando l'utente si trova su un dispositivo mobile. Scrivere una formula del flusso che controlli il valore della variabile globale $User.UIThemeDisplayed. Se il valore è Theme4t, l'utente sta compilando il modulo utilizzando l'app mobile Salesforce.

  • Valuta altre risorse: I riferimenti manuali alle variabili e alle formule vengono valutati solo sul server. Ciò significa che il valore che ha la 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 restituisce i valori delle variabili manuali e delle formule più recenti. Se si prevede che la regola di visibilità si aggiorni quando l'utente passa attraverso una singola schermata (ad esempio, onblur), è necessario assicurarsi di fare riferimento solo ai valori degli altri componenti della schermata.

• Con OmniStudio è possibile mostrare o nascondere i componenti in modo condizionale impostando una proprietà Visualizzazione condizionale. Tuttavia, non è possibile aggiungere più di una proprietà 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. LWC offre un controllo completo e reattivo sullo stato di input. Con i componenti Flusso schermata reattivo è possibile controllare dinamicamente gli attributi dei componenti (ad esempio, sola lettura, disabilitati e obbligatori) 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), utilizzare LWC a breve termine poiché 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

Se si stanno creando componenti LWC che possono reagire e modificare altri componenti in un flusso schermata, consultare la guida LWC Best Practices for Screen Flows per assicurarsi che i componenti si integrino con il motore di runtime del flusso e funzionino come previsto.

Per gli eventi personalizzati, se alcuni input (o l'intero modulo) devono comunicare con un altro elemento della pagina, LWC è l'unica opzione possibile.

• Per comunicare all'interno dello stesso albero DOM, utilizzare l'interfaccia CustomEvent.

• Per comunicare attraverso il DOM, utilizzare il servizio Lightning Messaging.

• Se Lightning Messaging Service non è supportato per il contenitore di destinazione, utilizzare il modulo pub/sub.

• Per informazioni più dettagliate, vedere Comunicazione con eventi e Comunicazione attraverso il DOM nella Lightning Web Components Dev Guide.

• Per OmniStudio, vedere Comunicazione con OmniScript da un componente Web Lightning.

Per offrire la migliore esperienza utente, è importante assicurarsi che lo stile del modulo sia coerente con il resto dell'app o del sito in cui viene incorporato. Ciò può significare utilizzare modelli standard forniti da Salesforce o creare un CSS personalizzato che utilizza ogni pixel nella progettazione per offrire un aspetto più nitido.

Gli amministratori possono configurare un insieme limitato di sostituzioni di stile schermata e componente (ad esempio, colori, bordi e aspetto dei pulsanti), per il contenitore schermata o per singoli componenti. Queste esclusioni vengono applicate dopo i temi e l'immagine aziendale, il che consente ai generatori di apportare modifiche visive mirate senza influire sul resto dell'applicazione.

Le esclusioni di stile sono destinate alle eccezioni visive localizzate (ad esempio, l'evidenziazione di una schermata di conferma o l'enfasi su un invito all'azione specifico; non sono un sistema di stile completo. Non offrono un controllo a livello CSS e non sono progettati per essere riutilizzati tra schermate o flussi.

Dal punto di vista architettonico, lo stile dovrebbe seguire questo ordine precedente:

1. Temi e immagine aziendale: Temi Lightning, set di immagini aziendali Generatore di esperienze o temi dei siti LWR

2. Sostituzioni dello stile del flusso: Rettifiche mirate della schermata o del componente

3. Componenti personalizzati (LWC): quando è necessario un controllo pixel-perfetto o modelli di progettazione riutilizzabili

L'uso di temi e sistemi di progettazione consente di garantire che lo stile rimanga coerente, scalabile e facile da mantenere nel tempo.

• Quanto sono sofisticati lo stile desiderato e CSS?

• Hai bisogno di uno stile personalizzato e pixel-perfect o temi standard?

FlexCard è l'unico prodotto in questa guida che consente di controllare in modo dichiarativo lo stile e il layout dell'interfaccia utente che si sta creando all'interno dello strumento (ad esempio, margini e riempimento, tipografia, colori e così via).

I moduli e i flussi dinamici rispettano le funzioni dichiarative dei temi. Se è necessario un ulteriore controllo (oltre a quello supportato da Temi Salesforce, Set di immagini aziendali Experience Builder o Siti Experience Cloud LWR), valutare una soluzione a livello di programmazione.

I team che utilizzano CSS hanno diverse opzioni:

• I flussi e i componenti LWC ereditano i token di progettazione.

• OmniScript e FlexCard includono il supporto del sistema di progettazione personalizzabile tramite Newport.

• Con LWC è possibile scrivere i propri componenti e controllarne completamente HTML e CSS.

Ove possibile, si consiglia di utilizzare temi e sistemi di progettazione per garantire un aspetto uniforme in tutti i contenuti.

Nota: È possibile incorporare componenti Lightning nei flussi. Se hai bisogno di un controllo pixel-perfetto sull'aspetto del modulo, ma vuoi anche utilizzare gli altri vantaggi dei flussi (ad esempio, il modello di navigazione), puoi avere 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.

• Come strutturare i layout dei moduli 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 layout a due colonne che possono essere suddivisi in singole sezioni all'interno dei campi. Queste sezioni possono essere inserite all'interno di componenti (ad esempio, schede e fisarmoniche) per creare layout organizzati e facili da usare.

Il rendering dei flussi può essere eseguito anche con il componente Sezione. È possibile aggiungere fino a quattro colonne e un numero illimitato di sezioni nella schermata del flusso. Il componente sezioni è anche reattivo alla larghezza dello schermo, quindi funziona anche su schermi più piccoli. Consente di applicare la visibilità condizionale all'intera sezione, semplificando l'applicazione globale della visibilità a più campi all'interno della sezione. Le sezioni flusso supportano anche le intestazioni di colonna e offrono un'esperienza simile a quella di 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 provengono da HTML e CSS. Il componente 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, lo è anche nel componente).

Se il modulo deve essere accessibile da utenti di regioni diverse o che parlano lingue diverse, è necessario assicurarsi che lo strumento utilizzato per crearlo soddisfi i requisiti di localizzazione.

Nota: Per i moduli in particolare, 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 si localizzano campi personalizzati, i moduli dinamici rispettano le etichette tradotte. I moduli dinamici rispettano anche tutte le etichette personalizzate assegnate alle etichette e agli attributi dei componenti nel Generatore di app Lightning.

Il flusso supporta la traduzione delle etichette rivolte agli utenti per tutti i componenti schermata standard e personalizzati tramite Area di lavoro traduzione.

È possibile localizzare etichette, testo della guida e messaggi di errore nei 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
• Password gruppo caselle di controllo
• Data
• Data/ora

Non è disponibile un supporto per la traduzione incorporato per le azioni pronte all'uso (ad esempio, Invia email o Pubblica su Chatter), ma esiste una soluzione. Se si utilizza un'etichetta personalizzata per definire le etichette tradotte, è possibile fare riferimento a tale etichetta personalizzata nell'azione o nel componente quando si configura in Flow Builder. A questo scopo, è necessario creare una formula del flusso che faccia riferimento all'etichetta personalizzata e quindi fare riferimento a tale formula nelle posizioni appropriate all'interno del flusso.

Gli OmniScript utilizzano etichette personalizzate per le traduzioni. Per ulteriori informazioni, consultare questo documento per verificare che gli OmniScript siano pronti per l'uso in più lingue.

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 configurati nell'Area di lavoro traduzione (ad esempio, Lightning-record-form).

Se è necessario introdurre nuove etichette traducibili nel codice, le etichette personalizzate sono la soluzione ideale. Dichiarare l'etichetta personalizzata necessaria e quindi importarla nel componente dal modulo con ambito @salesforce/label.

Utilizzare questa sezione per valutare i vincoli di sicurezza, qualità e operativi prima dell'implementazione.

La sicurezza è un argomento complesso e quando si tratta di creare moduli, ci sono una serie di considerazioni che potrebbero non essere ovvie. A livello di base, è necessario assicurarsi che il modulo venga eseguito nel contesto corretto e che gli utenti dispongano delle autorizzazioni necessarie per utilizzare i dati sottostanti. Oltre a ciò, si consiglia anche di adottare ulteriori misure per eliminare codice o URL potenzialmente dannosi dai campi di testo RTF, impedire a determinati utenti di accedere al modulo o imporre limitazioni ai tipi di posizioni in cui gli amministratori potrebbero incorporare il modulo in futuro.

Assicurarsi di documentare accuratamente i requisiti di sicurezza prima di scegliere uno strumento. Per ulteriori informazioni su questo tipo di documentazione, consultare il modello di policy Salesforce.

• 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 un programma viene eseguito nel contesto dell'utente, Salesforce impone una serie di controlli dell'accesso, che includono la verifica della protezione a livello di campo, delle autorizzazioni CRUD e dell'accesso ai record in base alle regole di condivisione dell'organizzazione (ad esempio, gli utenti potrebbero eseguire un modulo di aggiornamento dei casi solo se hanno la possibilità di aggiornare i casi, la protezione a livello di campo appropriata e l'accesso al record in questione).

Che cosa accade 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 che entra in gioco il contesto di sistema!

Contesto di sistema consente di elevare le autorizzazioni di un utente per la durata della sessione (ad esempio, l'utente non deve 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.

Contesto di sistema deve essere utilizzato solo quando è assolutamente necessario. Quando un modulo viene eseguito nel contesto di sistema, ogni operazione CRUD ignora i componenti di protezione e condivisione a livello di oggetto e di campo. Inoltre, il contesto di sistema non influisce su chi Salesforce considera l'attore (il nome visualizzato nel campo Ultima modifica di). Per ogni operazione eseguita dal modulo (ad esempio, l'aggiornamento di un caso), l'attore è l'utente corrente (anche se il modulo viene eseguito in un contesto diverso).

Nota: 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. È possibile decidere se il flusso deve concedere l'accesso a tutti i dati o imporre l'accesso a livello di record.

• Se si incorpora un componente Lightning in un flusso eseguito nel contesto di sistema, il flusso non sovrascriverà il contesto del componente. Se è necessario ignorare i controlli dell'accesso degli utenti, utilizzare il flusso per eseguire queste 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, sono coinvolte altre differenze.

  • Se la classe Apex è impostata sulla condivisione ereditata, verrà eseguita nel contesto di sistema con la condivisione indipendentemente da come è impostato il flusso.

  • Se la classe non ha una dichiarazione di condivisione esplicita, verrà eseguita nel contesto di sistema senza condivisione indipendentemente da come è impostato il flusso.

  • Se la classe è impostata con condivisione o senza condivisione, sovrascriverà il contesto del flusso.

Eseguire query sui 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 se non è autenticato), memorizzare solo campi specifici negli elementi Ottieni record. Quando si utilizza il 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 ispezionati dagli strumenti per sviluppatori del browser. Nonostante le intenzioni, i campi potrebbero essere resi disponibili agli utenti di Experience Cloud. Per assicurarsi che vengano visualizzati solo i campi corretti quando è abilitato il contesto di sistema, specificare tali campi specifici negli elementi Ottieni record.

Nota: 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 ai metodi Apex tramite gli strumenti per sviluppatori del browser. Quando si utilizza OmniScript, è importante eseguire la logica aziendale sul lato server (quando possibile) e implementare regole di convalida degli input per tutti i metodi Apex esposti tramite un'annotazione @InvocableMethod.

Sanificazione degli input

Per proteggere l'organizzazione dai malintenzionati, utilizzare la disinfettazione degli input. Si supponga di avere un input in un modulo accessibile pubblicamente che può essere mappato a un campo RTF dell'organizzazione. Può essere utile abilitare l'automazione che elimina qualsiasi codice HTML che potrebbe nascondere URL dannosi.

Non è l'ideale implementare la sanificazione a livello di modulo perché si può avere un numero qualsiasi di fonti che scrivono in questi campi. Per ovviare a questo problema, creare un Flusso aggiornamento campo veloce (prima del salvataggio) o utilizzare un trigger Apex esistente per eliminare o modificare qualsiasi potenziale HTML inserito nel modulo.

• Consentire l'esecuzione dei flussi nel loro contesto predefinito (a meno che non sia necessario elevare l'accesso dell'utente corrente per un'operazione specifica).

• Evitare di eseguire flussi nel contesto di sistema per gli utenti guest. Creare insiemi di autorizzazioni con accesso limitato ai campi e assegnarli al profilo dell'utente guest Experience Cloud.

• Quando si eseguono query sui record nel contesto di sistema Esegui flussi nei siti Experience Cloud, memorizzare solo i campi necessari nell'elemento Ottieni record o Azioni invocabili.

• Se un flusso esegue una varietà di operazioni, tutte senza accesso elevato, utilizzare i sottoflussi per isolare le operazioni che devono essere eseguite nel contesto di sistema.

• Se si incorpora un modulo in una pagina Web esterna, può essere necessario mapparlo ai campi RTF per evitare potenziali attacchi di phishing. Per farlo, disinfettare gli input degli utenti per rimuovere l'HTML utilizzando un Flusso aggiornamento campo rapido o un trigger Apex.

• 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.

• I flussi vengono eseguiti nel contesto dell'utente, ma è possibile ignorarli utilizzando un controller Apex.

• Le operazioni eseguite nell'API dell'interfaccia utente vengono eseguite nel contesto dell'utente.

• Le operazioni eseguite con un controller Apex dipendono dalla classe specifica. Per eseguire queste operazioni in modalità di sistema, impostare la classe Apex su con o senza condivisione.

Se è necessario controllare chi può accedere a un modulo, rivedere 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 sono sensibili, utilizzare le regole di visibilità per controllare ulteriormente gli elementi visualizzati a chi. Questa funzione si applica ai moduli dinamici e ai flussi schermata.

È possibile restringere un flusso a profili o insiemi di autorizzazioni particolari (in modo simile alla classe Apex o alle pagine Visualforce). I flussi non sono soggetti a restrizioni per impostazione predefinita, il che significa che qualsiasi utente con l'autorizzazione utente Esegui flussi può accedervi.

Se si utilizza OmniStudio, è possibile configurare un controllo autorizzazioni classe Apex che richiede agli utenti di avere accesso esplicito alla classe Apex che amministra le azioni remote dalle API OmniScript, Flexcard, Classic Card o REST.

Nota: I controlli delle autorizzazioni delle classi Apex si applicano solo alle classi Apex. Si consiglia inoltre di impostare le autorizzazioni a livello di profilo per Procedure di integrazione e Data Mappers.

• Se si espone un flusso agli utenti guest, è necessario concedere al profilo utente guest solo l'accesso ai flussi di cui hanno assolutamente bisogno. È possibile aggiungere Esegui flussi ai profili utente guest; tuttavia, questa procedura può essere rischiosa.

• Prestare attenzione quando si utilizzano flussi che operano nel contesto di sistema. È consigliabile limitare questi flussi a un determinato insieme di utenti, poiché dispongono di un minor numero di controlli e bilanciamenti per proteggere i dati.

• Assicurarsi che qualsiasi OmniScript che esegue Apex all'interno di una comunità di utenti guest disponga della condivisione elencata nella definizione della classe Apex.

• Per i profili utente guest, assegnare solo le classi Apex che si desidera consentire agli utenti guest di chiamare. Seguendo questa procedura, si evita di esporre involontariamente ulteriore logica aziendale agli utenti guest.

Per i componenti LWC, è possibile controllare le assegnazioni delle autorizzazioni dell'utente corrente per verificare se dispone di una determinata autorizzazione standard o personalizzata. È possibile importare le autorizzazioni Salesforce dai moduli con ambito @salesforce/userPermission e @salesforce/customPermission direttamente in JavaScript. È anche possibile utilizzare Apex per controllare le autorizzazioni.

I componenti LWC sono disponibili in una determinata posizione solo dopo essere stati aggiunti come destinazione valida (ad esempio, è possibile rendere un componente disponibile nelle pagine dei record e non disponibile come elemento della barra delle utilità).

Una volta attivato, un flusso schermata è disponibile in tutte le posizioni in cui sono supportati i flussi schermata. Flow Builder supporta più tipi di flussi con schermate. Il tipo più popolare è Flusso schermata, ma esistono alcuni altri tipi specializzati limitati a posizioni specifiche (ad esempio, l'app Field Service Mobile supporta solo i flussi Field Service Mobile). Questo è simile ai flussi Richiesta 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 è incorporato il flusso. I flussi sono disponibili in tutte le posizioni in cui è supportato quello specifico tipo di flusso.

Se si utilizza Salesforce Industries, viene visualizzato un piccolo avvertimento quando si tratta di OmniScript.Non è possibile specificare una destinazione per un OmniScript, ma è possibile specificare una destinazione per le FlexCard che si desidera incorporare.

In Salesforce sono disponibili diversi strumenti di automazione dei test end-to-end (ad esempio, Salesforce UTAM) che consentono di simulare come un utente interagisce con i moduli. È possibile scrivere test per qualsiasi interfaccia utente standard o personalizzata, incluse le pagine Lightning e i flussi schermata.

Nota: Questi tipi di test non possono verificare gli output per i metodi in esecuzione. Tenere presente quanto segue quando si configurano i requisiti di automazione dei test dell'interfaccia utente.

• Sono necessari test automatici per i moduli?

• Quali tipi di test si prevede di eseguire?

• Quale livello di dettaglio è necessario per le automazioni di test?

Considerare i requisiti di automazione dei test dell'interfaccia utente

I test di unità offrono un'automazione e una convalida granulari in linea con i sistemi e gli strumenti standard del settore per i CD/informatici, che testano la logica aziendale, i controlli JavaScript e gli output di componenti specifici. Se si sceglie un approccio low-code, non sarà possibile creare test da soli; tuttavia, Salesforce testa rigorosamente tutte le offerte end-to-end.

Se i metodi del componente sono complessi, è possibile inserirli singolarmente inserendoli in file JavaScript dedicati. Ciò consente di importarli in un LWC e quindi in un test Jest (ad esempio importare { sort } da 'c/utils';).

È possibile utilizzare una soluzione senza codice di un ISV, creare una soluzione di automazione dei test personalizzata o utilizzare un framework di test open source (ad esempio, Selenium WebDriver o WebdriverIO) per l'automazione end-to-end. Queste soluzioni sono valide per tutte le interazioni dell'interfaccia utente Salesforce (ad esempio, un modulo dinamico in una pagina Lightning, un flusso schermata in una barra delle utilità o un flusso LWC in un flusso di azione rapida).

Dopo aver distribuito il modulo in un ambiente di produzione, è necessario assicurarsi che venga utilizzato in modo efficace. A seconda del caso d'uso, ciò può significare tenere traccia del numero di volte in cui il modulo è stato compilato fino al tempo trascorso dall'utente medio a compilare il modulo prima di inviare le proprie informazioni. È importante identificare i KPI tracciabili prima di scegliere uno strumento.

• È necessario tenere traccia dell'utilizzo dei moduli?

• Quali KPI possono determinare se il modulo viene utilizzato in modo efficace?

Se è necessario tenere traccia dell'utilizzo e dell'adozione complessivi dei moduli, utilizzare strumenti low-code. I moduli dinamici e i flussi schermata sono tracciabili tramite rapporti personalizzati pronti all'uso. Tuttavia, i rapporti di tracciamento dei flussi schermata offrono una maggiore dettaglio. Se è necessario tenere traccia dell'utilizzo di LWC, la disponibilità pronta all'uso dipende da dove si utilizza LWC. Se si trova in una pagina Lightning, tutti gli elementi di tracciamento dell'utilizzo delle pagine Lightning disponibili sono validi anche per il componente LWC. Questo vale anche per i componenti LWC incorporati nei flussi.

I moduli dinamici non sono tracciabili immediatamente; tuttavia, è possibile tenere traccia dell'utilizzo della pagina Lightning controllante tramite gli oggetti Utilizzo Lightning. Per tenere traccia delle pagine Lightning standard, utilizzare il rapporto personalizzato Utenti con Lightning Usage by Page Metrics. Per le pagine Lightning personalizzate, utilizzare il rapporto personalizzato Utenti con Lightning Usage by FlexiPage Metrics.

I flussi possono aiutare a tenere traccia dell'adozione di moduli specifici. Utilizzare il rapporto flusso di esempio: Schermata Flussi per rispondere ai seguenti tipi di domande:

• Qual è la percentuale di completamento di questo modulo? Attualmente è ben adottato?

• Quanto tempo impiegano gli utenti a compilare questo modulo?

• Quale schermata viene completata più spesso dagli utenti?

• Con che frequenza gli utenti passano alle schermate precedenti?

• Con che frequenza si verificano gli errori?

Se il rapporto standard non soddisfa le proprie esigenze, è possibile clonarlo e apportare modifiche o Build Your Own report from scratch utilizzando il rapporto Flussi schermata.

Se si utilizza il runtime OmniScript basato su pacchetto, è anche possibile utilizzare OmniStudio per Vlocity Tracking Service. Questo servizio tiene traccia di tutti i tipi di eventi (ad esempio, è possibile tenere traccia del tempo necessario per completare i passaggi in un OmniScript, che consente di identificare i miglioramenti del processo).

Nota: Non esiste un'opzione pronta all'uso per tenere traccia di un LWC che non sia incorporato in una pagina Flusso schermata, OmniScript o Lightning, ma è possibile creare una soluzione personalizzata utilizzando Apex.

Forse si ha familiarità con l'utilizzo delle serie di modifiche o del DevOps Center per distribuire la soluzione agli ambienti di test o alla produzione. Queste opzioni di distribuzione supportano completamente moduli dinamici, flussi e componenti LWC. Tuttavia, OmniStudio richiede uno strumento separato, l'Area di lavoro IDX.

• Come si prevede di distribuire il modulo?

• Il modulo deve essere 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, consultare Moduli dinamici, flussi e componenti LWC. Tenere presente che Omnistudio non supporta la creazione di pacchetti.

Questa guida ha lo scopo di illustrare le funzionalità e i livelli di personalizzazione disponibili tramite moduli dinamici, flussi schermata, OmniStudio e LWC. Di seguito è riportata una panoramica generale.

• Quando si tratta di costruire forme, LWC è l'opzione più robusta e personalizzabile, ma ha il minor numero di guardrail in atto. Ecco perché è fondamentale creare i propri componenti con sicurezza e scalabilità.

• I moduli dinamici sono l'opzione meno flessibile, ma hanno molte meno possibilità di errori.

• Flusso e OmniStudio cadono leggermente nel mezzo. Sono più potenti dei moduli dinamici, ma non sono all'altezza del livello LWC. Tuttavia, hanno meno guardrail rispetto ai moduli dinamici e sono più difficili da violare rispetto al codice personalizzato.

È possibile che più strumenti soddisfino le proprie esigenze. In tal caso, la decisione dipende in ultima analisi dallo strumento più adatto al team. Per ulteriori informazioni sugli aspetti aggiuntivi da considerare, consultare le seguenti Guide alle decisioni dell'architetto.

• Quando si confrontano gli strumenti, è importante valutare quanta esperienza ha il team in relazione a ogni strumento?
• Quanti sviluppatori sono esperti di LWC o JavaScript?
• Ci sono sviluppatori nel team esperti in Flow Builder o che hanno espresso interesse a saperne di più?

Anche se non entreremo nei dettagli specifici, di seguito sono riportate alcune informazioni aggiuntive su come questi strumenti specifici sono correlati alle valutazioni che abbiamo trattato finora.

Delega consegna

Tenere presente che, anche se alcuni requisiti richiedono LWC, non è necessario che l'intera soluzione venga creata utilizzando LWC. È importante determinare come creare la soluzione in modo modulare. A questo scopo, è necessario identificare quali parti richiedono LWC codificato e quali no. Le parti che non richiedono LWC devono essere costruite utilizzando una soluzione low-code.

Quando si tratta di Flusso e LWC, esistono vari componenti (ad esempio, Componenti schermata reattivi e Flusso schermata) che possono essere sincronizzati tra loro nella stessa schermata per sbloccare nuovi strumenti per architetti, amministratori e sviluppatori. Gli sviluppatori possono ora creare componenti modulari mirati che possono essere riutilizzati in tutta l'organizzazione, il che contribuisce a migliorare la produttività dei team. Ciò consente agli sviluppatori di risparmiare tempo utilizzando un mix di componenti Flusso standard e personalizzati per ottenere un dinamismo della forma, che offre loro più tempo per concentrarsi sulla risoluzione di nuove sfide. Con l'introduzione dei componenti reattivi nel flusso, non c'è mai stato un momento più appropriato per combinare Flusso e LWC durante la creazione dei moduli.

Proprietà a lungo termine e manutenibilità

Se si sta creando un modulo a più fasi, iniziare con Flusso o un mix di Flusso e LWC. Se il team che gestisce il modulo è un team low-code, assicurarsi che la soluzione sia il più configurabile ed espandibile possibile per il pubblico a cui è destinata. Per migliorare la stabilità e la manutenibilità, è importante organizzare la soluzione in unità componibili, indipendentemente dallo strumento scelto.

Le considerazioni sulle prestazioni relative a moduli dinamici, flussi schermata, OmniStudio o LWC si basano sul framework in cui sono alloggiate le tecnologie. Le tecnologie basate su LWC tendono a superare quelle basate su Aura. A causa di diverse funzionalità principali implementate in modo nativo nei motori Web (anziché in JavaScript tramite astrazioni del framework), LWC offre vantaggi in termini di prestazioni avanzate.

Quindi, come sfruttare questi vantaggi in termini di prestazioni per le nostre tecnologie di forma in Salesforce? Vediamo in dettaglio.

• I moduli dinamici (integrati nei metadati delle pagine Lightning) sono basati su una base di stack LWC, che ci consente di implementare diverse funzioni molto attese. Come ulteriore vantaggio in termini di prestazioni, i moduli dinamici utilizzano il rendering progressivo, che migliora il tempo di caricamento per le pagine con un numero elevato di campi.

• I flussi schermata sono basati su LWC. La maggior parte dei singoli componenti pronti all'uso sono stati ora convertiti in LWC, ad eccezione dei componenti 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. Tenere presente che Salesforce supporta solo i componenti LWC all'interno del framework Componente reattivo nei flussi schermata. Per ulteriori informazioni, consultare il modulo Trailhead Lightning Web Components for Aura Developer. Se stai pensando di creare un componente personalizzato per un flusso schermata (o qualsiasi altro contenitore), scegli LWC!

• Sono disponibili diverse versioni di OmniStudio. Se si è un cliente di lunga data, è possibile che si utilizzi Angular. Invitiamo tutti i nuovi clienti a utilizzare OmniScript e FlexCard basati su LWC. Invitiamo inoltre i clienti esistenti a migrare da Angular.

• LWC è basato su LWC.