Vous souhaitez élaborer des formulaires sur Salesforce Platform ? Vous avez plusieurs options, couvrant tout le continuum code faible à pro-code. Les formulaires dynamiques dans le Générateur d'applications Lightning et les flux d'écran dans Flow Builder représentent le code faible. Au milieu du continuum, vous pouvez étendre les flux d'écran avec des composants Web Lightning et élaborer des formulaires accessibles aux clients avec OmniStudio. Et le pro-code est représenté par l'infrastructure LWC et sa bibliothèque sans cesse croissante de composants de base.

Les options sont excellentes, mais comment déterminer laquelle (ou quelle combinaison) est la bonne option ? C'est là que ce guide intervient.

• Leçon à retenir #1 : Lors de l'élaboration de présentations Créer/Modifier/Afficher pour des pages Lightning, utilisez des Formulaires dynamiques. Vous remarquerez que les présentations de page sont manquantes dans les tableaux de comparaison de ce guide. À l'avenir, la méthode recommandée pour configurer les pages de détail d'enregistrement est d'utiliser des Formulaires dynamiques dans le Générateur d'applications Lightning. Pour plus d'informations sur les raisons pour lesquelles nous ne prévoyons pas de les améliorer, consultez la section sur les présentations de page.
• A retenir #2 : Si vous devez créer ou modifier un formulaire pour un seul objet, commencez par les pages Lightning et les formulaires dynamiques. Cette méthode est la plus simple pour élaborer des formulaires sur Salesforce Platform. Il fournit également des fonctionnalités supplémentaires, notamment la possibilité de contrôler la visibilité du champ. Si vos exigences sont plus avancées, continuez à lire. Flux d'écran, OmniStudio ou Composants Web Lightning (LWC) peuvent être plus adaptés.
• A retenir #3 : Si vous élaborez un formulaire de plusieurs pages ou un assistant et que vous n'avez pas d'exigences strictes en matière d'utilisation de l'image de marque, commencez par un flux d'écran. Les flux d'écran fournissent une infrastructure de navigation linéaire pour orchestrer plusieurs formulaires ensemble. Vous pouvez utiliser LWC pour construire votre propre infrastructure de navigation entre les formulaires, mais nous recommandons de laisser Flow faire le travail difficile pour vous, afin de vous concentrer sur les formulaires eux-mêmes au lieu de vous soucier de l'état des formulaires.
• A retenir #4 : Si vous avez besoin d'une logique ou d'actions supplémentaires derrière le formulaire, utilisez un flux d'écran, OmniStudio ou LWC. Les trois outils offrent à votre solution d'autres possibilités que de créer ou de modifier un seul enregistrement. Ce « plus » peut correspondre à une logique plus avancée, par exemple branchement ou itération, ou à des actions plus poussées, par exemple intégration à des systèmes externes, envoi d'e-mails ou notifications automatiques à l'application mobile d'un utilisateur.
• A retenir #5 : Vous avez des exigences UX sophistiquées ? Vous devez gérer dynamiquement plus que la visibilité ? Utilisez LWC ou Omniscript. Si vous pouvez répondre à vos besoins avec un thème simple et des présentations basées sur des colonnes, vous pouvez élaborer vos formulaires directement dans un générateur à faible code. Pour mieux contrôler le style de votre formulaire, vous aurez besoin de la flexibilité ultime de LWC. Si vous êtes un client de Industries et que vous avez besoin d'une marque parfaite en pixels ou si vous avez des données hiérarchiques complexes, utilisez OmniStudio, qui vous permettra d'élaborer des formulaires de niveau consommateur capables de gérer une logique métier complexe et des transformations de données.
• A retenir #6 : Si vous avez besoin d'automatisation test, commencez par Lightning Web Components. Vous pouvez écrire des tests unitaires pour n'importe quel LWC, quel que soit l'emplacement où vous envisagez de l'incorporer. Vous pouvez ainsi créer une stratégie de test plus robuste, qui peut inclure des tests en masse avec plusieurs enregistrements et des tests négatifs. Pour plus d'informations sur la création de tests, consultez Salesforce Well-Architected - Testing Strategy qui vous aidera à déterminer si vos formulaires répondent à vos exigences fonctionnelles et non fonctionnelles.

Gardez à l'esprit que votre choix ne doit pas nécessairement être un ou deux - vous pouvez combiner la puissance de plusieurs options. Par exemple, si vous avez besoin à la fois du système de navigation intégré de Flow et de la flexibilité de style totale offerte par LWC, utilisez-les ensemble.

Le tableau ci-dessous présente les outils disponibles pour élaborer des formulaires avec Salesforce, ainsi que leurs compétences requises et les considérations relatives aux licences. Plus loin, nous approfondirons les fonctionnalités spécifiques prises en charge pour chaque outil, ainsi que la façon de choisir entre les outils basés sur le clic et les outils basés sur le code (et quand les combiner) :

Le tableau ci-dessous présente un aperçu des points de décision à prendre en compte lors de vos sélections de produits, ainsi que les questions que vous devriez vous poser sur chacun d'eux. Nous approfondirons chacun de ces sujets dans le reste de ce guide.

Voici les termes que nous utilisons dans les tableaux de comparaison avec leurs définitions :

• Disponible : Fonctionne bien avec les considérations de base.
• Pas idéal : Peut fonctionner, mais n'est pas l'outil optimal.
• Feuille de route : Appui estimé dans les douze prochains mois (juin 2025).
• Futur: Estimation du support au-delà des douze prochains mois.
• Non disponible : Il n'est pas prévu de prendre en charge cette capacité dans les douze prochains mois.

Comme promis, commençons par explorer une variété de points de comparaison et de différences fonctionnelles entre les formulaires dynamiques, les flux d'écran, OmniStudio, les flux d'écran avec des composants Web Lightning incorporés et l'infrastructure LWC elle-même.

Si votre formulaire fonctionne avec un seul objet Salesforce, tous les outils que nous comparons fonctionnent. Les choses se compliquent un peu avec les formulaires inter-objets ou agnostiques aux objets. Par agnostique d'objet, nous entendons les entrées qui ne sont mappées avec aucun objet Salesforce. Votre formulaire peut représenter une structure de données que vous allez envoyer à un service externe, par exemple Stripe ou DocuSign. Alternativement, vous utilisez plusieurs entrées dans votre formulaire pour calculer une valeur, puis validez cette valeur dans la base de données.

• Avec quels objets le formulaire fonctionnera-t-il ?
• Est-ce un seul objet ou existe-t-il plusieurs objets ?
• Vous travaillez avec des objets spécifiques (par exemple Compte, Contact, Opportunité, Piste et Requête) ou votre formulaire doit-il également fonctionner avec d'autres objets ?

Pour les formulaires inter-objets et agnostiques aux objets, Flow et OmniStudio sont des options solides. Les composants disponibles dans les écrans de flux sont agnostiques par nature. Par conséquent, vous pouvez choisir quoi faire en arrière-plan avec ces données. Utilisez par exemple les données saisies dans un formulaire pour créer plusieurs enregistrements en arrière-plan, ou utilisez les données pour exécuter d'autres actions telles que générer des publications Chatter, envoyer des messages Slack, envoyer des e-mails ou vous connecter à des services externes.

Pour des cas simples, l'utilisation de composants LWC existants, tels que Lightning, peut être un moyen simple de réduire le code nécessaire pour fournir une solution robuste. Cependant, pour les scénarios dans lesquels plusieurs objets sont impliqués, Flow fournit un contrôle complet de tous les objets et élimine la nécessité pour les développeurs de traverser des relations et des dépendances complexes.

OmniStudio va plus loin et est complètement agnostique en matière d'objets : il sépare le formulaire affiché par l'utilisateur du modèle de données sous-jacent. À la place, OmniStudio manipule le JSON sous-jacent qui est ensuite mappé avec des objets Salesforce (ou des données externes) en utilisant des outils tels que Data Mapper et Procédures d'intégration. Data Mapper et les procédures d'intégration sont deux composants clés pour connecter vos formulaires OmniStudio à des données internes et externes à Salesforce. En utilisant des éléments par glisser-déposer, vous pouvez travailler avec des données hiérarchiques complexes dans un système externe, puis transformer les données pour les adapter à vos besoins en fonction de l'emplacement où les données doivent aller. Ils permettent également d'utiliser des formules pour effectuer des calculs mathématiques et logiques sur des tableaux, ou des listes de données, un peu comme Apex.

Intégrations OmniStudio

Si vous pouvez obtenir toutes vos entrées utilisateur à partir d'un formulaire à écran unique, commencez par les Formulaires dynamiques. Cependant, bien que les formulaires dynamiques dans les pages d'enregistrement puissent utiliser la fonctionnalité Parcours pour représenter vaguement les diverses étapes de votre processus métier, elle peut ne pas correspondre à la majorité de vos cas d'utilisation.

• Avez-vous besoin d'un seul écran ou l'utilisateur doit-il naviguer entre plusieurs écrans pour réaliser une tâche ?
• Voulez-vous que vos utilisateurs affichent une représentation visuelle de leur progression dans le processus de remplissage de votre formulaire ?
• Vos utilisateurs devront-ils remplir les informations de chaque écran dans un ordre spécifique ou pourront-ils passer d'un écran à l'autre si nécessaire ?

Si vous avez besoin de fonctionnalités supplémentaires que celles offertes par les formulaires dynamiques, le choix entre Flow, OmniStudio et LWC dépendra également de quelques autres questions :

• Quelles sont les compétences de votre équipe ? Pour une organisation plus lourde en administrateurs, nous recommandons de commencer par Flux. Si vous avez des solutions Industries, que votre équipe connaît déjà OmniStudio et que votre projet a des exigences UX strictes, commencez par OmniStudio.
• Vous pouvez afficher une barre de navigation en bas de votre formulaire ? Si le flux d'écran et l'expérience de navigation Omniscript sont indésirables UX, penchez-vous vers LWC.
• Que doit-il se passer derrière le formulaire ? Si vous souhaitez que le comportement soit configurable par un administrateur, élaborez un flux ou, pour des modifications de base telles que la modification des étiquettes de champ, un Omniscript. Sinon, pour des relations complexes et multi-objets, élaborez un Omniscript ou Composant Web Lightning.
• Si vous choisissez Flow ou OmniStudio, il peut être nécessaire d'élaborer un LWC de toute façon pour obtenir l'expérience utilisateur appropriée. Si vous élaborez déjà un composant Web Lightning pour appliquer un style correct à votre formulaire, déterminez si l'incorporation de ce composant dans un flux est excessive.

Si, par contre, votre solution ressemble à un assistant, où l'utilisateur navigue entre plusieurs écrans, pensez à Flow ou OmniStudio. Les flux et OmniStudio sont fournis avec un modèle de navigation intégré. Il n'est pas nécessaire d'élaborer et de gérer des composants Web Lightning enchaînés. La navigation est linéaire, avec des actions d'avance, des actions de recul et un mécanisme de sauvegarde du formulaire pour plus tard. Vous pouvez également élaborer un formulaire avec une navigation non linéaire si cela vous convient. Par exemple, en utilisant des flux d'écran, consultez le package Digital Store Audit de Salesforce Labs.

OmniStudio offre un avantage de navigation clé en fournissant des indicateurs de progression à partir de la navigation standard qui exposent des « étapes » dans le formulaire. Cette vue d'étape affiche automatiquement l'emplacement d'un utilisateur dans un formulaire à plusieurs étapes donné. Contrairement à Flux, il permet aux utilisateurs de « sauter » entre les écrans en cliquant sur diverses étapes du formulaire.

Que vous élaboriez des formulaires à écran unique ou multi-écrans, assurez-vous que vos formulaires sont rationalisés afin de faciliter leur navigation pour vos utilisateurs.

Si vous incorporez un formulaire à une page d'enregistrement Lightning standard, n'importe quel outil que nous comparons fonctionnera, avec la mise en garde que les Formulaires dynamiques ne sont actuellement disponibles que sur ordinateur de bureau. Cependant, si vous souhaitez offrir une expérience permettant aux utilisateurs d'accéder aux formulaires à partir d'autres emplacements, il peut être nécessaire d'envisager d'autres options.

• Les utilisateurs devront-ils accéder au formulaire par ordinateur de bureau, appareil mobile ou les deux ?
• Les utilisateurs doivent-ils pouvoir accéder au formulaire n'importe où dans votre application via une barre d'utilitaires ?
• Voulez-vous utiliser des actions rapides pour permettre aux utilisateurs de remplir votre formulaire sans quitter la page où ils se trouvent actuellement ?
• Votre formulaire doit-il être disponible sur un site Web externe ?

Comme ils nécessitent un contexte d'enregistrement, les Formulaires dynamiques sont pris en charge uniquement dans les pages d'enregistrement Lightning. Cependant, les formulaires dynamiques ne sont pas pris en charge dans les pages Experience Cloud. Cette limitation est en place, car Experience Cloud n'utilise pas l'infrastructure sous-jacente dont dépendent les Formulaires dynamiques : Pages Lightning. Nous évaluons cela en fonction des demandes de Formulaires dynamiques dans Experience Cloud.

Vous pouvez élaborer des flux qui nécessitent un contexte d'enregistrement ou des flux qui fonctionnent globalement. Vous pouvez ainsi incorporer des flux à divers emplacements. Pour des flux contextuels d'enregistrement, il peut s'agir d'une page d'enregistrement Lightning, d'une page d'enregistrement Experience Cloud, d'une action spécifique à un objet ou d'un déploiement Actions et recommandations. Pour le flux global, il peut s'agir de la barre d'utilitaires, d'autres pages Lightning ou Générateur d'expérience, d'un Snap ou d'une application externe. Actuellement, les flux ne sont pas pris en charge en tant qu'actions globales, mais en tant que solution de contournement, vous pouvez inclure le flux dans un composant Aura.

OmniStudio permet d'élaborer des FlexCards et des Omniscripts composables que vous pouvez placer presque partout où vous pouvez placer un flux. Cependant, bien que composables, ils ne peuvent pas être empaquetés.

LWC prend en charge un degré élevé de réutilisation, car vous créez des composants qui peuvent être associés à des cibles via des métadonnées dans Salesforce, des communautés et même dans des projets open-source. Les composants LWC peuvent également être incorporés à votre propre site Web via Lightning Out.

Lightning Out sur les sites externes

Actuellement, les composants Web Lightning ne sont pas pris en charge en tant qu'actions rapides (spécifiques à un objet ou globales), mais comme solution de contournement, vous pouvez envelopper un composant LWC dans un composant Aura (un peu comme vous le pouvez avec des flux). Les composants LWC peuvent également lancer des flux avec le composant Lightning-flow.

OmniStudio excelle dans l'exposition de contenus à vos sites externes via la fonctionnalité OmniOut. Avec OmniStudio et OmniOut, vous pouvez compiler vos formulaires Omniscript et composants FlexCard dans des composants standard et les exécuter hors plate-forme dans des sites ou des applications tiers.

Aucune des technologies de formulaire présentées dans ce guide n'est officiellement prise en charge dans les modèles Mobile SDK aujourd'hui. Si le kit de développement Mobile SDK est essentiel à votre cas d'utilisation, vous feriez mieux d'élaborer votre formulaire en natif dans votre application mobile ou d'élaborer une page Visualforce, tout en gardant à l'esprit le guide du facteur de forme Salesforce Well-Architected.

Note de la feuille de route : L'équipe Mobile SDK travaille activement sur la prise en charge des composants Web Lightning dans les pages Visualforce.

Les formulaires dynamiques sont parfaits si vous devez utiliser les valeurs de votre formulaire pour créer ou mettre à jour un enregistrement. Pour toutes les capacités au-delà, vous devez exploiter Flow, OmniStudio ou LWC. Ces capacités peuvent inclure une couche de décision ou d'itération, ou la génération de publications ou d'e-mails Slack en utilisant les entrées du formulaire.

• Quelles actions ou logiques souhaitez-vous exécuter en arrière-plan ?
• Votre modèle de données contient-il des données hiérarchiques ?
• Votre formulaire devra-t-il effectuer ses opérations dans une seule transaction ou dans plusieurs transactions ?
• Avez-vous besoin d'intégrer des systèmes externes ?
• Quelles sont vos exigences en matière de réutilisabilité et de modularité ?

Flow offre des actions standard pour publier dans Slack, envoyer un e-mail et interagir avec des documents Quip. Il n'est pas nécessaire d'écrire de code pour ces opérations. LWC offre des interactions enrichies avec des enregistrements uniques et des objets associés en utilisant des adaptateurs wire qui interagissent avec l'API Interface utilisateur. LWC peut également interagir avec plusieurs enregistrements en utilisant le wire pour getListInfoByName.

Interaction LWC via des adaptateurs WireInteraction des composants Web Lightning via des adaptateurs Wire __

Comme mentionné ci-dessus, OmniStudio utilise des procédures d'intégration et Data Mapper pour récupérer et transformer aisément des données externes et internes à Salesforce. Il brille dans l'aplatissement et l'expansion des jeux de données avec divers niveaux de relations grâce à de nombreuses fonctions sans code que vous pouvez utiliser.

Note de la feuille de route : Flow va bientôt prendre en charge la mise à jour/insertion de collections d'enregistrements, ainsi que la gestion des données hiérarchiques.

Flow, OmniStudio et LWC s'intègrent tous à Apex. Par conséquent, vous pouvez aisément combler les écarts dans la solution que vous choisissez. Par exemple, si vous avez besoin de filtrer les enregistrements d'un LWC vous pouvez toujours utiliser l'adaptateur wire pour Apex afin de créer des requêtes SOQL complexes. Si vous êtes influencé par le récit basé sur le clic, considérez Flow ou OmniStudio comme des alternatives viables à un contrôleur Apex pour vos besoins côté serveur.

Une deuxième question est de savoir si vous souhaitez engager immédiatement des actions ou les reporter à une partie particulière de votre formulaire. Cela est particulièrement important si vous utilisez un formulaire de plusieurs pages. Le flux facilite la combinaison des entrées de plusieurs formulaires (écrans de flux) et leur utilisation beaucoup plus tard dans l'assistant (flux) pour effectuer certaines opérations. En fait, nous recommandons de concevoir des flux de cette façon (exécuter des actions à la fin) au cas où l'utilisateur rebondirait entre les écrans, changeant ses réponses.

Les transactions et les limites du gouverneur sont un mode de vie sur Salesforce Platform. Si votre cas d'utilisation est assez simple, il peut ne pas être aussi important de contrôler la transaction dans laquelle une opération particulière se produit. Cependant, il existe quelques cas d'utilisation dans lesquels vous pouvez combiner plusieurs opérations dans une seule transaction plutôt que de les exécuter dans plusieurs transactions. Quelques exemples :

• Pour annuler ou ne pas annuler: Telle est la question. Supposons que votre formulaire crée plusieurs enregistrements en arrière-plan. Si la création du troisième enregistrement échoue, les deux premiers enregistrements doivent-ils être annulés ? Si chacune de vos actions est indépendante, n'hésitez pas à les exécuter dans des transactions séparées. Cependant, si elles sont dépendantes et que vous souhaitez que l'échec de l'une annule également les autres, implémentez-les dans une transaction unique. Si votre formulaire est dans Flux, vous pouvez utiliser l'élément Restaurer dans un chemin Défaut pour annuler votre transaction et garantir l'intégrité des données.
• Impact en aval sur les limites du gouverneur: En particulier, lorsque votre formulaire crée ou met à jour un enregistrement, tenez compte des implications en aval de cette opération. Quels processus, règles de workflow, déclencheurs de flux, déclencheurs Apex ou autres éléments de l'ordre d'enregistrement vont se déclencher en fonction de ce changement d'enregistrement ? Quel est l'impact de ces changements collectifs sur les limites du gouverneur consommées dans cette transaction ? Si un changement d'enregistrement particulier entraîne de nombreuses modifications en aval qui impactent vos limites, vous pouvez isoler ce changement d'enregistrement dans sa propre transaction.
• Traitement par lot: Même dans un contexte d'interface utilisateur, il peut être nécessaire de regrouper plusieurs mises à jour par lot. Supposons que votre formulaire à écrans multiples itère sur un grand nombre d'enregistrements. Au lieu de valider une mise à jour d'enregistrement après chaque écran, attendez d'avoir collecté les mises à jour de tous les enregistrements, puis soumettez une requête pour mettre à jour tous les enregistrements.

Lorsque vous utilisez des Formulaires dynamiques pour créer ou modifier un enregistrement, vous n'exécutez qu'une seule opération, qui marque toujours le début d'une nouvelle transaction.

Lors de l'élaboration d'un flux d'écran, vous avez un contrôle important sur ce qui se passe dans une transaction donnée. Les écrans et les actions locales agissent en tant que frontières entre les transactions. Voici un résumé général de la gestion des transactions dans l'architecture de flux d'écran.

1. L'utilisateur interagit avec un écran, puis clique sur Suivant.
2. Le client publie une requête à l'API avec les entrées.
3. L'API reçoit la requête, et une transaction et une connexion à la base de données sont ouvertes. L'API appelle ensuite le moteur de flux pour invoquer la requête.
4. Le moteur de flux prend le relais et suit le chemin approprié dans la définition du flux, jusqu'à ce qu'il atteigne un nœud Écran ou Action locale. Le moteur renvoie ensuite des informations sur ce nœud à l'API.
5. L'API crée un objet de réponse qui contient les détails de l'écran suivant à restituer, puis renvoie cet objet au client. À ce stade, les modifications de la base de données sont validées (récupérer l'exécution de commande), et la connexion à la base de données et la transaction sont fermées.
6. Le client utilise la réponse d'API pour restituer l'écran suivant avec lequel l'utilisateur peut interagir.
7. Répétez l'étape 1.

En d'autres termes, les écrans « cassent » les transactions. Dans ce cas, toutes les actions en attente ou DML sont engagées, la transaction précédente est fermée et une nouvelle transaction démarre.

La conception appropriée, c'est-à-dire les opérations que vous regroupez dans une transaction donnée, est votre choix. Examinons quelques exemples.

À gauche, vous pouvez voir un flux qui collecte les entrées sur plusieurs écrans, puis exécute plusieurs actions dans une seule transaction.

Le flux à droite effectue chaque opération dans une transaction séparée.

Supposons que vous avez un flux qui crée des enregistrements, met à jour des enregistrements, puis crée d'autres enregistrements, comme illustré dans le flux suivant à droite.

Dans ce scénario, si les deux premiers éléments réussissent et que le dernier échoue, les deux premières opérations DML créeront et mettront à jour ces enregistrements, alors que le troisième échouera.

En utilisant l'élément Restaurer les enregistrements, vous pouvez vous assurer que la transaction complète est annulée si les trois opérations doivent être exécutées simultanément, comme indiqué dans le flux final à gauche.

Pour plus d'informations, consultez Flux dans Transactions et En masse dans Transactions. La section Automatisé de Salesforce Well-Architected approfondit également ce point dans Data Handling.

Votre capacité à contrôler la transaction à partir d'un LWC se résume aux services sous-jacents que LWC utilise pour effectuer ses opérations. Si vous utilisez le composant de base Lightning, l'opération sous-jacente (création ou mise à jour de l'enregistrement) se produit dans une transaction autonome dès que le formulaire est soumis.

En général, les règles suivantes s'appliquent :

• Chaque appel d'API d'interface utilisateur est isolé dans sa propre transaction.
• Si vous devez effectuer plusieurs opérations dans la même transaction, envoyez les entrées à une technologie côté serveur, par exemple un contrôleur Apex ou un flux. Les règles de transaction habituelles de cette technologie s'appliquent.

Flow, OmniStudio et LWC prennent tous en charge les événements de plate-forme (pour l'architecture pilotée par événement) et les intégrations d'API. En plus d'un code Apex personnalisé, Flow et OmniStudio prennent en charge des mécanismes déclaratifs pour intégrer une API.

Si vous devez vous connecter à une API Mulesoft ou à un robot RPA, utilisez les Services Mulesoft. Cela génère un Service externe.

Intégrations externes via des API Mulesoft et des robots RPA

Si l'API a un schéma OpenAPI, créez un Service externe.

Intégrations externes à des API avec des schémas OpenAPI

Sinon, utilisez la fonctionnalité Appel externe HTTP dans Flux ou Action HTTP dans OmniStudio. L'appel externe HTTP du flux est piloté par les Services externes.

Intégrations externes via HTTP

OmniStudio offre un riche ensemble de capacités d'intégration qui peuvent appeler des systèmes externes avec des procédures d'intégration et transformer les données avec Data Mapper. (pour plus d'informations, consultez Impact sur l'objet)

Que vous l'implémentiez avec Apex personnalisé ou un service externe, un appel externe est un appel externe. Voici ce que vous devez savoir.

1. Un appel externe peut être long.
2. Lorsqu'un appel externe est exécuté de façon synchrone, il est exécuté alors qu'une transaction de base de données est ouverte.
3. Salesforce ne permet pas de garder une transaction de base de données ouverte si vous avez des opérations de base de données en attente.

La principale limitation à prendre en compte est le danger des transactions sales, dans lesquelles vous effectuez une opération de création, de mise à jour ou de suppression, puis exécutez un appel externe dans la même transaction. Ce modèle n'est pas autorisé en raison de la considération #3 ci-dessus, qui existe bien sûr en raison des considérations #1 et #2.

Dans Flux, vous pouvez contourner cette limitation en rompant la transaction. Notez que les écrans et les actions locales réintroduisent le contexte du navigateur, ce qui rompt la transaction. Bien que vous puissiez utiliser des écrans et des actions locales lors de l'utilisation d'appels externes, nous recommandons d'activer le Contrôle des transactions dans les paramètres avancés invocables. Le contrôle des transactions est une fonctionnalité d'actions invocables qui permet de terminer automatiquement la transaction avant qu'un appel externe soit passé. Vous pouvez activer le Contrôle des transactions en sélectionnant Toujours démarrer une nouvelle transaction dans la section Avancé d'une action invoquée.

Pour plus d'informations sur les appels externes Apex, les services externes et les capacités d'intégration de données en général, consultez le Architect's Guide to Data Integration with Salesforce.

Les formulaires dynamiques ne prennent pas en charge la réutilisation. Chaque Formulaire dynamique est lié à une page d'enregistrement Lightning spécifique pour un objet spécifique (vous pouvez toutefois attribuer cette page d'enregistrement Lightning à plusieurs applications, profils, etc.).

De la même façon que vous pouvez écrire des bibliothèques, des utilitaires et des composants destinés à être utilisés dans plusieurs autres composants, vous pouvez appliquer des modèles de conception similaires en créant des flux avec la puissance des flux secondaires. Enregistrez vos flux dans des compartiments plus petits et plus modulaires, puis appelez-les à partir d'autres flux en utilisant l'élément Flux secondaire. Si votre conception l'exige, vous pouvez élaborer un flux autonome et utile en tant que flux secondaire d'un autre flux.

OmniStudio est intrinsèquement construit pour la modularité. Les mappeurs de données, les Omniscripts, les FlexCards et les procédures d'intégration sont tous élaborés indépendamment et peuvent fonctionner de façon interchangeable. En plus de cela, les FlexCards peuvent être élaborées en tant que composants LWC qui peuvent être incorporés à d'autres composants LWC, Omniscripts, pages d'enregistrement et sites Experience Cloud.

Les flux d'écran, les Omniscripts et les Composants Web Lightning peuvent tous être conçus pour être réutilisés et incorporés à divers emplacements, y compris des sites externes et des applications Lightning Out. Lorsque vous concevez vos solutions pour qu'elles soient composables, vous bénéficiez d'avantages supplémentaires tels que l'adaptabilité et la stabilité.

Toutes les technologies utilisées pour créer ou mettre à jour un enregistrement adhèrent à la validation au niveau du système, qu'il s'agisse de règles de validation classiques ou d'une validation personnalisée intégrée à un déclencheur Apex. Quelle que soit la technologie utilisée pour effectuer un changement d'enregistrement, chaque modification passe par l'ordre d'enregistrement. Cela signifie qu'en plus des règles de validation, le changement d'enregistrement est traité par n'importe quel nombre de flux avant ou après la sauvegarde, avant ou après les déclencheurs, les règles d'escalade, les règles d'attribution, et plus encore. Si ce n’est déjà fait, assurez-vous de mettre l’ordre d’exécution Apex dans vos favoris et de vous familiariser avec lui.

• Votre formulaire a-t-il des exigences supplémentaires que la validation au niveau système ?
• Devrez-vous définir dynamiquement des champs obligatoires ou en lecture seule dans le formulaire ?

Les entrées dans un écran de flux ou une étape Omniscript sont par nature non liées. Par conséquent, le formulaire lui-même n'adhère pas nativement à la validation au niveau système associée à un objet particulier. Cependant, les valeurs que vous utilisez pour créer ou mettre à jour des enregistrements sont traitées par l'ordre d'enregistrement, ce qui signifie qu'elles sont transmises par la validation au niveau système de l'objet. Notez toutefois que les composants de flux d'écran ne prennent pas tous en charge la validation des entrées. À compter de la version Summer '24, les autres composants d'écran qui ne prennent pas en charge la validation des entrées sont les cases d'option, les listes de sélection, les listes à sélection multiple, les groupes de cases à cocher et les références de choix.

De la même façon que les présentations de page, les formulaires dynamiques permettent de définir l'exigence et l'état en lecture seule au niveau de la page. Cependant, vous ne pouvez pas remplacer les paramètres au niveau système.

Le flux offre la flexibilité nécessaire pour personnaliser la validation dans les entrées d'un formulaire. Bien que certaines vérifications soient effectuées dans le client (notamment le marquage de champs obligatoires manquants ou de valeurs incompatibles), aucune validation côté client n'empêche l'utilisateur d'essayer de naviguer. La véritable validation se produit sur le serveur. Lorsqu'un utilisateur clique sur Suivant, Flux envoie les entrées au serveur pour validation. Si des entrées sont renvoyées comme non valides, la navigation est bloquée et l'erreur appropriée est affichée. Le serveur valide les entrées en cochant :

1. Le paramètre d'exigence de l'entrée, ou si la valeur saisie est compatible avec le type de données sous-jacent.
2. Validation personnalisée sur cette entrée : Plusieurs composants standard (case à cocher, devise, date, date/heure, zone de texte longue, numérique, mot de passe et texte) prennent en charge la validation personnalisée par écran. Saisissez une expression de formule booléenne et un message d'erreur à afficher lorsque l'expression de formule n'est pas remplie.
3. Validation personnalisée dans le composant sous-jacent : Si vous élaborez un composant Web Lightning personnalisé pour un flux, ajoutez votre propre code de validation à la méthode validate().

OmniStudio offre un traitement enrichi des erreurs et de la validation via l'action Définir l'erreur combinée à des vues conditionnelles et au composant Messagerie.

Du côté LWC, la plupart des composants de base effectuent leurs propres validations côté client. Par exemple, Lightning respecte l'exigence au niveau système, mais pas au niveau de la page. Pour vos composants personnalisés, vous pouvez Build Your Own mécanismes de validation.

Les champs qui nécessitent que les utilisateurs saisissent des données doivent être affichés tôt dans vos formulaires. Dans la mesure du possible, validez les entrées des utilisateurs côté client avant de soumettre les formulaires. Pour plus d'informations sur les meilleures pratiques de rationalisation de vos formulaires, consultez le guide des formulaires dans Salesforce Well-Architected - Engaging.

La sécurité est un sujet complexe en général, et quand il s'agit d'élaborer des formulaires, il y a un certain nombre de considérations auxquelles vous n'avez peut-être même pas pensé. Au niveau fondamental, vous devez vous assurer que le formulaire est exécuté dans le contexte approprié et que les utilisateurs disposent des autorisations requises pour utiliser ses données sous-jacentes. Au-delà de cela, vous pouvez également prendre des mesures supplémentaires pour retirer les codes ou URL potentiellement malveillants des champs de texte enrichi, empêcher certains utilisateurs d'accéder au formulaire ou limiter les types d'emplacement où les administrateurs peuvent incorporer le formulaire à l'avenir. Assurez-vous de bien documenter vos exigences de sécurité avant de choisir un outil. Le modèle de stratégie Salesforce Well-Architected contient des consignes relatives à ce type de documentation.

• Le formulaire doit-il vérifier l'accès de l'utilisateur avant d'effectuer certaines opérations ?
• Devriez-vous désinfecter les entrées des utilisateurs ?
• Voulez-vous contrôler qui peut accéder au formulaire ?
• Voulez-vous contrôler l'emplacement où le formulaire peut être incorporé ?

Lorsqu'un élément est exécuté dans le contexte utilisateur, Salesforce applique une série de contrôles d'accès, notamment la vérification de la sécurité au niveau du champ, des autorisations CRUD et de l'accès aux enregistrements en fonction des règles de partage de votre organisation. Par exemple, les utilisateurs peuvent exécuter un formulaire de mise à jour de requête uniquement s'ils ont la possibilité de mettre à jour les requêtes, la sécurité au niveau du champ appropriée et l'accès à l'enregistrement en question. Que se passe-t-il si vous souhaitez que les utilisateurs puissent exécuter une opération particulière lorsqu'ils utilisent votre formulaire, mais pas via un autre formulaire ou une autre interaction ? C'est là qu'intervient le contexte système.

Le contexte système permet d'augmenter les autorisations de l'utilisateur actif pendant la durée de la session, afin qu'il n'ait pas besoin, par exemple, de mettre à jour l'accès à l'objet Requête pour remplir votre formulaire de mise à jour de requête. Ceci est particulièrement utile pour les communautés non authentifiées. Au lieu d'accorder aux utilisateurs invités des capacités potentiellement dangereuses, définissez l'exécution de votre formulaire dans le contexte système.

Bien sûr, le contexte système est une arme à double tranchant et vous devez l'utiliser uniquement lorsque nécessaire. Lorsqu'un formulaire est exécuté dans le contexte système, chaque opération CRUD contourne la sécurité et le partage au niveau de l'objet et du champ, pas seulement l'opération spécifique qui vous intéresse. Notez également que le contexte système n'a aucune incidence sur qui Salesforce considère l'acteur, le nom affiché dans le champ Dernière modification par. Pour chaque opération que votre formulaire effectue, par exemple la mise à jour de requête, l'acteur est l'utilisateur actif, même si le formulaire est exécuté dans un contexte différent.

Les formulaires dynamiques, les Omniscripts et les composants Web Lightning sont toujours exécutés dans le contexte de l'utilisateur, et il n'est pas possible de remplacer ce comportement.

Les flux d'écran sont exécutés par défaut dans le contexte de l'utilisateur, mais vous pouvez les définir pour les exécuter dans le contexte système. Vous pouvez choisir si le flux doit accorder l'accès à toutes les données ou s'il doit toujours appliquer l'accès au niveau de l'enregistrement, par exemple le partage.

• Si vous incorporez un composant Lightning à un flux exécuté dans le contexte système, le flux ne remplace pas le contexte du composant. Si vous devez contourner les contrôles d'accès des utilisateurs, nous recommandons d'utiliser le flux pour effectuer ces opérations et transmettre les données appropriées dans ou hors du composant Lightning. Certains composants prêts à l'emploi (tels que Référence) ne peuvent pas fonctionner dans le contexte système.
• Si votre flux appelle des actions Apex, il y a quelques nuances supplémentaires à comprendre. Si la classe Apex est définie sur le partage hérité, elle est exécutée dans le contexte système avec partage quel que soit le flux défini. Si la classe n'a pas de déclaration de partage explicite, elle est exécutée dans le contexte système sans partage, quel que soit le flux défini. Si la classe est définie sur avec partage ou sans partage, elle le fait et remplace le contexte du flux.

Interrogation d'enregistrements dans le contexte système avec des sites Experience Cloud :

Si vous exécutez un flux en contexte système sur un site Experience Cloud, notamment non authentifié, nous recommandons de stocker uniquement des champs spécifiques dans vos éléments Obtenir des enregistrements. Lorsque vous travaillez avec Flow et transmettez les résultats d'un élément Obtenir des enregistrements dans un flux secondaire, une action invocable ou un composant Lightning, tous les champs de cet objet peuvent être inspectés via les outils pour développeur du navigateur. Cela peut rendre les champs disponibles pour les utilisateurs de votre site Experience Cloud que vous n'avez peut-être pas l'intention. En spécifiant des champs spécifiques dans vos éléments Obtenir des enregistrements, vous pouvez vous assurer que seuls les champs appropriés sont exposés, même lorsque le contexte système est activé.

Notez que la logique Omniscript est exécutée côté client, ce qui permet aux assaillants de modifier l'exécution attendue d'un Omniscript _et d'_afficher les réponses aux appels de méthode Procédures d'intégration, Mappeurs de données et Apex en utilisant les outils de développement du navigateur. Lorsque vous utilisez Omniscript, nous recommandons d'exécuter une logique métier côté serveur dans la mesure du possible et d'implémenter des règles de validation d'entrée dans toutes les méthodes Apex exposées via une annotation @InvocableMethod.

Intrants d'assainissement :

Pour protéger votre organisation contre les mauvais acteurs, pensez également à la désinfection des entrées. Supposons que vous avez une entrée dans un formulaire accessible au public qui peut être mappée avec un champ Texte enrichi dans votre organisation. Vous pouvez envisager une automatisation qui supprime tout code HTML susceptible de masquer des URL malveillantes. En général, il n'est pas idéal d'implémenter cette désinfection au niveau du formulaire, car vous pouvez avoir n'importe quel nombre de sources qui écrivent dans ces champs. Nous recommandons de créer un flux de mise à jour de champ rapide (avant la sauvegarde) ou d'utiliser un déclencheur Apex existant dans l'objet pour retirer ou modifier tout code HTML potentiel qui pourrait être saisi dans le formulaire.

Meilleures pratiques :

• Laissez les flux s'exécuter dans leur contexte par défaut, sauf si vous devez augmenter l'accès de l'utilisateur actif à une opération spécifique.
• Évitez d'exécuter des flux dans le contexte système pour les utilisateurs invités pour des raisons de sécurité. Créez à la place des ensembles d'autorisations avec un accès limité aux champs attribué au profil utilisateur invité du site Experience Cloud.
• Lorsque vous interrogez des enregistrements dans des flux exécutés en contexte système sur des sites Experience Cloud, stockez uniquement les champs dont vous avez besoin dans votre élément Obtenir des enregistrements ou Actions invocables.
• Si un flux exécute diverses opérations et qu'elles ne nécessitent pas toutes un accès élevé, utilisez des flux secondaires pour isoler les opérations qui doivent être exécutées dans le contexte système.
• Si vous envisagez d ' incorporer un formulaire à une page Web externe, envisagez d ' assainir les entrées des utilisateurs pour retirer le code HTML en utilisant un flux de mise à jour rapide des champs ou un déclencheur Apex s ' ils sont mappés avec des champs de texte enrichi afin d ' éviter toute attaque potentielle par hameçonnage de la part de mauvais acteurs.

• Les Omniscripts, les FlexCards et les Composants Web Lightning sont exécutés par défaut dans le contexte de l'utilisateur.
• Les LWC sont exécutés dans le contexte utilisateur par défaut et les flux sont exécutés dans le contexte utilisateur mais vous pouvez remplacer cela dans un contrôleur Apex.
• Les opérations effectuées via l'API UI sont exécutées dans le contexte de l'utilisateur.
• Les opérations effectuées via un contrôleur Apex dépendent de cette classe. Pour effectuer ces opérations en mode système, définissez la classe Apex sur avec partage ou sans partage.

Si vous avez besoin de contrôler qui peut accéder à votre formulaire, vous pouvez souvent consulter le conteneur dans lequel le formulaire est incorporé. Vous pouvez par exemple attribuer des pages Lightning pour qu'elles soient disponibles pour des applications, des types d'enregistrement ou des profils particuliers. Si certaines entrées de votre formulaire sont confidentielles, utilisez des règles de visibilité pour mieux contrôler les éléments affichés pour qui. Cette fonctionnalité s'applique aux Formulaires dynamiques et aux flux d'écran.

Vous pouvez limiter un flux à des profils ou des ensembles d'autorisations particuliers, de la même façon qu'une classe Apex ou une page Visualforce. Par défaut, les flux ne sont pas restreints, ce qui signifie que tout utilisateur disposant de l'autorisation Exécuter des flux peut les exécuter.

Si vous utilisez OmniStudio, vous pouvez configurer un vérificateur d'autorisations pour vous assurer que les utilisateurs ont besoin d'un accès explicite à la classe Apex qui administre l'action distante appelée à partir d'une API Omniscript, Flexcard, Classic Card ou REST.

• Remarque Les contrôles d'autorisation de classe Apex sont activés par défaut pour les scripts nouvellement créés. Cependant, ils doivent être activés manuellement pour tous les scripts existants
• Notez également que les contrôles d'autorisation des classes Apex s'appliquent uniquement aux classes Apex. Nous recommandons de définir également des autorisations au niveau du profil pour les Procédures d'intégration et les Mappeurs de données.

Pour plus d'informations et les meilleures pratiques sur les autorisations utilisateur invité, consultez :

• Meilleures pratiques d'accès aux enregistrements utilisateur invité
• Développer des sites sécurisés : Utilisateurs authentifiés et invités

Meilleures pratiques :

• Si vous exposez un flux à des utilisateurs invités, accordez au profil utilisateur invité l'accès uniquement aux flux dont il a besoin. Bien qu'il soit possible d'ajouter Exécuter des flux au profil utilisateur invité, nous considérons cette pratique comme risquée.
• Soyez particulièrement prudent avec les flux qui fonctionnent dans le contexte système. Nous recommandons vivement de limiter ces flux à un groupe particulier d'utilisateurs, car ils ont moins de freins et contrepoids en place pour protéger vos données.
• Assure-toi que tout Omniscript qui exécute Apex dans une communauté d'utilisateurs invités a "avec partage" dans la définition de la classe Apex.
• Dans votre profil Utilisateur invité, attribuez uniquement les classes Apex que les utilisateurs invités peuvent appeler, sinon vous risquez d'exposer involontairement une logique métier supplémentaire aux utilisateurs invités.

Pour les composants Web Lightning, vous pouvez vérifier les attributions d'autorisations de l'utilisateur actif afin de vérifier s'il dispose d'une autorisation standard ou personnalisée particulière. Directement depuis JavaScript, vous pouvez importer des autorisations Salesforce à partir des modules d'étendue @salesforce/userPermission et @salesforce/customPermission. Ou vous pouvez utiliser Apex pour vérifier la même chose.

Les composants Web Lightning sont disponibles à un emplacement donné uniquement lorsqu'ils ont été ajoutés en tant que cible valide. Vous pouvez par exemple rendre un composant disponible dans des pages d'enregistrement et non disponible en tant qu'élément de la barre d'utilitaires.

Lorsqu'un flux d'écran est activé, il est disponible à tous les emplacements où les flux d'écran sont pris en charge, que vous souhaitiez ou non qu'il soit disponible partout. Cela dit, Flow Builder prend en charge plusieurs types de flux qui ont des écrans. Le type pain et beurre est Flux d'écran, mais il existe d'autres types spécialisés limités à des emplacements spécifiques. Par exemple, l'application mobile Field Service prend en charge uniquement - vous l'aurez deviné - les flux mobiles Field Service. Il en va de même pour les flux de demande de contact, qui sont pris en charge uniquement dans Experience Cloud.

Quel que soit le type de flux, l'individu qui crée le flux n'a aucun contrôle sur l'emplacement où le flux peut être incorporé. Le flux sera disponible à chaque emplacement pris en charge pour ce type de flux.

Si vous utilisez Salesforce Industries, une petite mise en garde s'applique à Omniscript : Vous ne pouvez pas spécifier une cible pour un Omniscript lui-même, mais vous pouvez en spécifier une pour les FlexCards que vous souhaitez incorporer.

Les formes statiques appartiennent au passé. Aujourd'hui, il s'agit de mettre à jour dynamiquement le formulaire avec les propriétés et les valeurs appropriées pour cet utilisateur, cette fois, cet endroit. Parlons de ce qui est possible dans cette veine pour les outils de création de formulaires de Salesforce.

• Quels types d'interaction ou de condition doivent déclencher des réponses dynamiques dans votre formulaire ?
• Vous devrez exécuter des opérations hors écran en arrière-plan pendant que votre formulaire est rempli ?
• Devrez-vous définir des champs comme visibles, obligatoires, en lecture seule ou désactivés, ou changer la mise en forme en fonction des entrées de formulaire ?

L'interactivité des flux d'écran est désormais une réalité grâce aux écrans réactifs. La réactivité permet aux composants individuels d'un écran de flux de communiquer entre eux, ce qui augmente infiniment la puissance des flux d'écran.

Exécuter des opérations de données hors écran : Les flux d'écran offrent une approche déclarative pour récupérer des données sur le même écran via des Actions d'écran. Les actions d'écran peuvent vous permettre de déclencher des flux lancés automatiquement lors de n'importe quelle modification à l'écran ou lorsqu'un utilisateur clique sur un composant Bouton d'action. Vous pouvez ensuite mapper les résultats de ces flux lancés automatiquement avec le même écran, ce qui évite aux utilisateurs d'accéder à un autre écran.

LWC offre une gamme complète d'adaptateurs wire qui permettent d'accéder aux données Salesforce pour remplir dynamiquement les données des composants de votre formulaire, et permet aux développeurs de mettre à jour, de supprimer et de créer des enregistrements via des contrôleurs Apex.

Composants Web Lightning Opérations de données hors écran

Visibilité : La visibilité peut être contrôlée dynamiquement dans tous les outils de création de formulaires. Les formulaires dynamiques, Flow Builder et OmniStudio répondent à ce problème avec les fonctionnalités de visibilité des composants. Vous pouvez ainsi afficher ou masquer par déclaration des champs basés sur d'autres valeurs du formulaire ou si l'utilisateur est sur un appareil mobile ou non.

• Avec les formulaires dynamiques, la visibilité peut être contrôlée en fonction des valeurs de champ d'enregistrement, des enregistrements associés via des champs de référence et du facteur de forme.
• Avec Flux, vous pouvez baser une règle de visibilité sur d'autres entrées à l'écran, ainsi que sur d'autres ressources remplies précédemment dans le flux, notamment des formules ou des valeurs d'autres enregistrements.
  • Règles basées sur l'appareil : Ce n'est pas évident dès le départ, mais vous pouvez utiliser une formule pour afficher ou masquer un champ particulier lorsque l'utilisateur est sur un appareil mobile. Écrivez une formule de flux qui vérifie la valeur de la variable globale $User.UIThemeDisplayed. Si la valeur est Theme4t, l'utilisateur est dans l'application mobile Salesforce.
  • Évaluation d'autres ressources : Les références manuelles de variables et de formules sont évaluées uniquement sur le serveur. Par conséquent, quelle que soit la valeur de cette ressource lors de la restitution initiale de l'écran, elle sera définie jusqu'à ce que vous accédiez à un autre écran. Lors de la navigation, l'exécution du flux soumet une requête au moteur de flux (le serveur) et récupère les toutes dernières valeurs des variables manuelles et des formules. Si vous souhaitez que votre règle de visibilité soit mise à jour lorsque l'utilisateur traverse un écran unique (par exemple, onblur), assurez-vous de référencer uniquement les valeurs des autres composants de l'écran.
• Avec OmniStudio, vous pouvez afficher ou masquer des composants sous certaines conditions en configurant une Propriété Vue conditionnelle. Cependant, vous ne pouvez pas ajouter plusieurs propriétés de vue conditionnelle pour une entrée.

États d'entrée conditionnels : Si vous devez contrôler dynamiquement d'autres propriétés, par exemple si un champ est obligatoire, désactivé ou en lecture seule, vous avez plusieurs options. Comme prévu, LWC vous donne un contrôle complet et réactif de votre état d'entrée. Avec les composants Flux d'écran réactifs, vous pouvez contrôler dynamiquement les attributs de composants tels que Lecture seule, Désactivé et Obligatoire pour les composants standard qui le prennent en charge, tandis qu'OmniStudio prend en charge l'éventail complet des attributs spécifiques au composant. Si vos exigences exigent un flux et que le composant ne prend pas en charge un état d'attribut spécifique, vous pouvez créer un composant Web Lightning incorporable pour obtenir un état d'entrée dynamique.

Si vous devez contrôler dynamiquement d'autres propriétés, par exemple si un champ est obligatoire ou en lecture seule, votre meilleur pari à court terme est LWC, où vous avez le contrôle total. Cela est particulièrement vrai si vous avez des exigences sur mesure pour gérer onblur ou onclick.

Composants Web Lightning réactifs dans les flux d'écran : Lors de l'élaboration de composants Web Lightning capables de réagir et de modifier d'autres composants dans un flux d'écran, consultez ce guide LWC Best Practices for Screen Flows pour vous assurer que vos composants s'intègrent correctement au moteur d'exécution du flux et fonctionnent normalement à l'avenir.

Maintenant pour les événements personnalisés. Si certaines de vos entrées ou le formulaire complet doivent communiquer avec autre chose dans la page, LWC est votre seule option.

• Pour communiquer dans la même arborescence DOM, utilisez l'interface CustomEvent.
• Pour communiquer à travers le DOM, utilisez Lightning Messaging Service.
• Si Lightning Messaging Service n'est pas pris en charge pour votre conteneur cible, utilisez le module pub/sub.

• Pour plus de détails, consultez Communicating with Events and Communicate Across the DOM dans le Lightning Web Components Dev Guide.
• Pour OmniStudio, consultez Communiquer avec Omniscript à partir d'un composant Web Lightning.

Pour offrir la meilleure expérience utilisateur, vous devez vous assurer que le style de votre formulaire est cohérent avec le reste de l'application ou du site dans lequel il est incorporé. Cela peut signifier n'importe quoi, depuis l'utilisation de modèles standard fournis par Salesforce jusqu'à la création de CSS personnalisées qui utilisent entièrement chaque pixel de la conception pour offrir une présentation plus nette.

• Quel est le niveau de sophistication de votre style et CSS ?
• Avez-vous besoin d'un style personnalisé et parfait pour les pixels ou êtes-vous d'accord avec les thèmes standard ?

FlexCards est le seul produit couvert dans ce guide qui permet de contrôler par déclaration le style et la présentation de l'interface utilisateur que vous élaborez directement dans l'outil, que ce soit les marges et le remplissage, la typographie, les couleurs, etc.

Les formulaires dynamiques et les flux respectent les fonctionnalités de thème déclaratif. Si vous avez besoin d'un contrôle au-delà des Thèmes Salesforce, des Ensembles de personnalisations Générateur d'expérience ou des Sites Experience Cloud LWR, envisagez une solution par programmation.

Pour les équipes qui maîtrisent le CSS, vous avez deux options :

• Les flux et les composants Web Lightning héritent de jetons de conception standard.
• Les Omniscripts et les FlexCards prennent en charge un système de conception personnalisable : Newport.
• Avec LWC, vous pouvez écrire vos propres composants et contrôler entièrement le code HTML et CSS.

Dans la mesure du possible, nous recommandons d'utiliser des thèmes et des systèmes de conception afin d'appliquer votre présentation de façon cohérente à l'ensemble de vos contenus.

Rappel : Vous pouvez incorporer des composants Lightning dans des flux. Par conséquent, si vous avez besoin d'un contrôle parfait de la présentation de votre formulaire, mais souhaitez utiliser les autres avantages des flux, tels que le modèle de navigation, vous pouvez avoir le meilleur des deux mondes. Le même principe s'applique aux Omniscripts et aux FlexCards.

Le choix d'une bonne présentation est crucial pour concevoir des formulaires rationalisés qui permettent une saisie rapide et efficace des données et augmentent leur intégrité. Pour plus d'informations sur cette rubrique, consultez Salesforce Well-Architected - Forms.

• Comment utiliser la présentation de votre formulaire pour optimiser l'expérience utilisateur ?
• Comment présenter à vos utilisateurs des données existantes qui facilitent la saisie de nouvelles données dans vos formulaires ?

Les formulaires dynamiques prennent en charge les présentations à deux colonnes et peuvent être divisés en sections individuelles avec des champs. Ces sections peuvent être placées dans des composants tels que des onglets et des accordéons pour créer des présentations faciles à utiliser et organisées.

Les flux peuvent être restitués en utilisant le composant Section. Avec des sections, vous pouvez ajouter jusqu'à quatre colonnes et autant de sections que vous le souhaitez à l'écran de flux. Le composant est également réactif à la largeur de l'écran, ce qui lui permet de travailler sur des écrans plus petits. Enfin, il permet d'appliquer une visibilité conditionnelle à toute la section, ce qui facilite l'application en masse de la visibilité à plusieurs champs de la section. Les sections de flux prennent également en charge les en-têtes de colonne et offrent une expérience en accordéon dans laquelle les utilisateurs peuvent réduire la section complète en cliquant sur l'étiquette.

Les Omniscripts offrent diverses options de présentation pour l'affichage des champs et des données. Vous pouvez créer des sections de données contenant jusqu'à 12 colonnes, y compris des accordéons réductibles sous certaines conditions.

Avec LWC, vous pouvez utiliser Lightning-[edit|view]-form et le champ Lightning-[input|output]-field de support pour contrôler la présentation. Les seules restrictions de présentation sont celles de HTML/CSS. Lightning respecte la configuration de la section dans la présentation de page associée. Par exemple, si une section est à deux colonnes dans la présentation de page, elle est à deux colonnes dans ce composant.

Si votre formulaire est accessible par des utilisateurs de différentes régions ou qui parlent différentes langues, vous devez vous assurer que l'outil que vous allez utiliser pour l'élaborer répond à vos exigences de traduction. Pour plus d'informations et des recommandations, consultez Salesforce Well-Architected - Localization. Dans le cas des formulaires en particulier, les exigences de localisation impliquent généralement la traduction d'éléments de texte dans d'autres langues.

• Votre formulaire sera-t-il utilisé dans plusieurs pays ou régions ?
• Le texte de votre formulaire doit-il être traduit dans d'autres langues ?

Si vous avez traduit vos champs personnalisés, ces étiquettes traduites sont respectées dans les Formulaires dynamiques. Les formulaires dynamiques respectent également les étiquettes personnalisées que vous avez attribuées aux étiquettes et aux attributs des composants dans le Générateur d'applications Lightning.

Grâce à la puissance du Système de traduction, Flow prend en charge la traduction des étiquettes accessibles à l'utilisateur pour tous les composants d'écran standard et personnalisés. Vous pouvez localiser l'étiquette, le texte d'aide et le message d'erreur des composants d'écran suivants : Texte, Zone de texte longue, Numérique, Devise, Case à cocher, Cases d'option, Liste de sélection, Liste à sélection multiple, Groupe de cases à cocher, Mot de passe, Date et Date/heure.

Il n'y a pas de prise en charge de la traduction intégrée pour les actions prêtes à l'emploi, telles que Envoyer un e-mail ou Publier dans Chatter. Cependant, il existe une solution de contournement ! Si vous définissez les étiquettes traduites avec une étiquette personnalisée, vous pouvez référencer cette étiquette personnalisée dans l'action ou le composant en la configurant dans Flow Builder. Créez une formule de flux qui référence l'étiquette personnalisée, puis référencez cette formule aux emplacements appropriés de votre flux.

Les Omniscripts utilisent des étiquettes personnalisées pour les traductions. Consultez ce document pour préparer vos Omniscripts multilingues.

Maintenant pour LWC. Certains composants de base héritent automatiquement des traductions des champs, du texte d'aide et des messages de validation de l'objet associé s'ils ont été configurés dans le Système de traduction (par exemple : Lightning).

Si vous devez introduire de nouvelles étiquettes traduisibles dans votre code, les étiquettes personnalisées restent le héros méconnu. Déclarez l'étiquette personnalisée dont vous avez besoin, puis importez-la dans votre composant depuis le module d'étendue @salesforce/label.

Plusieurs outils d'automatisation de test de bout en bout sont disponibles (par exemple, Selenium), qui vous permettront de simuler l'interaction de l'utilisateur avec votre formulaire. Vous pouvez écrire ces tests pour n'importe quelle interface utilisateur standard ou personnalisée, y compris les pages Lightning et les flux d'écran. Cependant, il est important de noter que ces types de test ne peuvent pas vérifier les sorties de chaque méthode exécutée. Assurez-vous d'en tenir compte en réfléchissant à vos exigences en matière d'automatisation des tests d'interface utilisateur.

• Avez-vous besoin de tests automatisés pour votre formulaire ?
• Quels types de test devez-vous effectuer ?
• Quel niveau de granularité faut-il pour vos automatisations de test ?

Tenez compte de vos exigences en matière d'automatisation des tests d'interface utilisateur.

Les tests unitaires permettent une automatisation et une validation plus précises qui fonctionnent avec les systèmes et les outils CI/CD standard de l'industrie, qui peuvent tester la logique métier des composants, son contrôleur JavaScript et ses sorties. En utilisant exclusivement le code faible, vous ne pourrez pas créer vous-même des tests, mais Salesforce teste rigoureusement nos offres de bout en bout.

Si les méthodes de votre composant sont suffisamment complexes pour être testées individuellement, placez-les dans des fichiers JavaScript dédiés. Vous pouvez ainsi les importer dans un LWC et dans un test Jest avec quelque chose comme import { sort } from 'c/utils';.

Consultez Interface utilisateur Test Automation on Salesforce pour comparer les diverses options disponibles pour élaborer une automatisation de bout en bout dans Salesforce. Les considérations comprennent quand utiliser une solution sans code d'un éditeur de logiciels, Build Your Own solution d'automatisation de test personnalisée ou utiliser une infrastructure de test de source ouverte telle que Selenium WebDriver ou WebdriverIO. Ces solutions sont valables pour n'importe quelle interaction d'interface utilisateur dans Salesforce, qu'il s'agisse d'un Formulaire dynamique dans une page Lightning, d'un flux d"écran dans une barre d'utilitaires ou d'un LWC dans un flux dans une action rapide.

Après avoir déployé votre formulaire dans un environnement de production, vous devez vous assurer qu'il est utilisé efficacement. Selon votre cas d'utilisation, cela peut signifier n'importe quoi, du simple suivi du nombre de fois qu'il a été rempli au temps que les utilisateurs passent à le remplir avant de soumettre leurs informations. Assurez-vous d'identifier les indicateurs de performance clés que vous souhaitez suivre avant de choisir un outil.

• Avez-vous besoin de suivre l'utilisation de votre formulaire ?
• Quels indicateurs de performance clés détermineront si votre formulaire est utilisé efficacement ?

Si vous devez suivre l'utilisation globale et l'adoption de votre formulaire, commencez par les outils à faible code. Les formulaires dynamiques et les flux d'écran peuvent être suivis en utilisant des types de rapport personnalisés prêts à l'emploi, mais les rapports de suivi des flux d'écran offrent plus de précision. Si vous devez suivre l'utilisation d'un Composant Web Lightning, la disponibilité prête à l'emploi dépend de l'emplacement où vous utilisez ce Composant Web Lightning. S'il se trouve dans une page Lightning, les éléments disponibles pour le suivi de l'utilisation des pages Lightning s'appliquent à vos composants Web Lightning. Même chose pour les composants Web Lightning incorporés à des flux.

Les formulaires dynamiques eux-mêmes ne peuvent pas être suivis prêts à l'emploi, mais vous pouvez suivre l'utilisation de la page Lightning parente via des objets Lightning Pour suivre les pages Lightning standard, utilisez le type de rapport personnalisé Utilisateurs avec Lightning Usage by Page Metrics (Utilisation de Lightning par métriques de page). Pour les mêmes pages Lightning personnalisées, utilisez le type de rapport personnalisé Users with Lightning Usage by FlexiPage Metrics.

Pour suivre l'adoption de votre formulaire spécifique (pas seulement de la page dans laquelle il réside), Flow s'occupe de vous. Utilisez « Exemple de rapport de flux : Flux d'écran » pour répondre à des questions telles que :

• Quel est le taux de remplissage de ce formulaire ? Est-ce bien adopté?
• Combien de temps faut-il aux utilisateurs pour remplir ce formulaire ?
• Sur quel écran les utilisateurs passent-ils le plus de temps ?
• À quelle fréquence les utilisateurs reculent-ils ?
• À quelle fréquence les erreurs se produisent-elles ?

Si le rapport standard ne répond pas à vos besoins, clonez-le pour apporter vos propres modifications ou Build Your Own en utilisant le type de rapport Screen Flows (flux d'écran).

Si vous utilisez l'exécution Omniscript basée sur un package, vous pouvez utiliser le service OmniStudio pour Vlocity Tracking. Ce service suit n'importe quel type d'événement. Vous pouvez par exemple suivre le temps nécessaire pour suivre les étapes d'un Omniscript afin d'identifier les améliorations à apporter au processus. Il figure sur la feuille de route de l'équipe OmniStudio pour prendre en charge ce service dans OmniStudio standard.

Pour suivre la même chose pour un LWC qui n'est pas incorporé à un flux d'écran, un Omniscript ou une page Lightning, aucune option prête à l'emploi n'existe. Vous pouvez élaborer en utilisant Apex une solution personnalisée.

Lorsque vous devez déployer votre solution dans des environnements supérieurs pour la tester ou la déployer en production, vous pouvez être habitué à utiliser pour cela des ensembles de modifications ou DevOps Center. Les formulaires dynamiques, les flux et les composants Web Lightning sont entièrement pris en charge dans ces options de déploiement. OmniStudio nécessite un outil séparé : IDX Workbench.

• Comment comptez-vous déployer votre formulaire ?
• Votre formulaire sera-t-il distribué à plusieurs organisations Salesforce ?

Si vous êtes un éditeur de logiciels ou un partenaire qui envisage d'empaqueter votre solution pour la distribuer sur AppExchange, nous recommandons d'examiner d'abord les formulaires dynamiques, les flux et les composants Web Lightning. OmniStudio ne prend pas en charge l'empaquetage.

Ce guide vise à vous aider à comprendre les fonctionnalités et le niveau de personnalisation possibles avec les formulaires dynamiques, les flux d'écran, OmniStudio et LWC. À un niveau élevé :

• LWC est l'option la plus personnalisable et robuste pour construire un coffrage, mais il a le moins de garde-fous en place. Il vous revient d'élaborer un composant de manière à garantir la sécurité et l'évolutivité.
• Les formulaires dynamiques sont les moins flexibles, mais les possibilités de faux pas sont beaucoup moins nombreuses.
• Flow et OmniStudio se situent quelque part au centre – plus puissants que les formulaires dynamiques, mais pas tout à fait au niveau des composants Web Lightning. De la même façon, ils ont moins de garde-fous que les formulaires dynamiques, mais sont plus difficiles à briser que le code personnalisé.

Si plusieurs outils correspondent à la facture, la décision dépend de l'outil approprié pour votre équipe. D'autres guides de décision introduisent des aspects supplémentaires à prendre en compte lors de la prise de décision.

Nous n’entrerons pas dans les détails de chacun de ces aspects ici, mais nous les interpréterons pour les outils spécifiques que ce document évalue.

Compétences spécialisées: Quelle est l'expertise de votre équipe dans les outils que vous comparez ? Combien de fabricants connaissent bien et maîtrisent LWC ou JavaScript ? Que diriez-vous des fabricants experts en Flow Builder ou qui ont exprimé leur intérêt à tremper leurs orteils ? Généralement, les compétences Formulaires dynamiques et Flux sont plus accessibles pour une population élargie de personnes qui élaborent des formulaires. Formulaires dynamiques est l'outil de création de formulaire le plus déclaratif et sera toujours plus facile à apprendre que Flux. Cela dit, l'équipe de Flow s'engage à réduire cette barre au maximum. En termes de complexité, OmniStudio se situe quelque part entre Flow et LWC et offre d'importants superpouvoirs de création de formulaire.

Délégation de livraison: Ce n'est pas parce que certaines de vos exigences nécessitent des composants Web Lightning que votre solution complète doit être élaborée avec des composants Web Lightning. Examinez comment élaborer votre solution de façon modulaire, de sorte que les pièces qui nécessitent un composant Web Lightning soient codées et celles qui ne le nécessitent pas soient élaborées dans une solution à faible code. Cela optimise l'efficacité d'une équipe diversifiée et garantit que chaque individu résout les problèmes appropriés à sa spécialisation.

Parlons maintenant de Flow et de LWC. Avec les composants d'écran réactifs, les composants de flux d'écran peuvent désormais se parler sur le même écran, ce qui libère un tout nouveau coffre à outils pour les architectes, les administrateurs et les développeurs. Les développeurs peuvent désormais créer des composants modulaires et utiles qui peuvent être réutilisés dans l'ensemble de l'organisation, ce qui augmente la productivité de tous les membres de l'équipe. Les développeurs peuvent se concentrer sur la résolution de nouveaux défis et gagner du temps en utilisant une combinaison de composants Flux standard et personnalisés pour obtenir un dynamisme de forme. Avec des composants réactifs dans Flux, il n'a jamais été aussi opportun de mélanger Flux et Composants Web Lightning lors de l'élaboration de vos formulaires.

Maintenabilité et propriété à long terme: Si vous avez un formulaire à plusieurs étapes, il est recommandé de commencer par Flux ou un mélange de Flux et de Composants Web Lightning. Si vous avez une équipe low-code qui gère la solution, pensez à comment la rendre aussi configurable et extensible que possible pour cette audience. Quel que soit l'outil choisi, organisez votre solution en unités composables pour améliorer la maintenabilité et la stabilité.

À l'avenir, la méthode recommandée pour configurer les pages de détail d'enregistrement est Formulaires dynamiques dans le Générateur d'applications Lightning utilisant des pages Lightning. Il y a longtemps que nous n'avons pas amélioré les présentations de page, et cette tendance va se poursuivre. Voici pourquoi :

• Les formulaires dynamiques sont plus flexibles. Vous pouvez placer des champs et des sections où vous le souhaitez directement dans le Générateur d'applications Lightning, où vous pouvez tirer parti des sections, des onglets et des accordéons. Et tout comme vous pouvez le faire avec des composants de la page Lightning, vous pouvez contrôler la visibilité de vos champs et sections sans définir plusieurs présentations de page ou types d'enregistrement.
• Avec les composants Accordéon et Onglet, vous pouvez limiter le nombre de champs initialement affichés. Devine ce que ça veut dire ? Accélération des temps de chargement de page.
• La gestion des présentations est plus simple avec les pages Lightning, puisque vous pouvez tout gérer sur vos pages depuis le Générateur d'applications Lightning - que ce soit le contenu de la page ou les utilisateurs qui ont accès à la page. Il n'est plus nécessaire d'effectuer des mises à jour dans votre présentation de page pour effectuer une modification dans votre page Lightning. Sans oublier que grâce à la puissance des règles de visibilité, il n'est plus nécessaire de créer plusieurs pages (ou présentations de page) pour contrôler qui voit quels champs quand. Et cela signifie également que vous devez seulement attribuer aux utilisateurs une page Lightning plutôt que d'attribuer à la fois une page Lightning et une présentation de page.

Nous recommandons d'utiliser des Formulaires dynamiques dans la mesure du possible et de revenir aux présentations de page uniquement si nécessaire. Comme toujours, nous accueillons les commentaires dans l'Échange d'idées sur les améliorations qui auraient le plus d'impact pour votre organisation.

Toutes les considérations relatives aux performances liées aux formulaires dynamiques, aux flux d'écran, à OmniStudio et aux composants Web Lightning sont centrées sur l'infrastructure dans laquelle ces technologies s'inscrivent. Ceux qui sont basés dans LWC (en plus, bien sûr, un LWC) vont surpasser ceux qui sont basés à Aura. L'infrastructure LWC offre de meilleures performances, car les fonctionnalités principales sont implémentées nativement dans les moteurs Web au lieu de JavaScript via des abstractions d'infrastructure. Si vous ne connaissez pas, lisez ce billet de blog.

En 2019, nous avons réalisé une étude de cas comparant les performances de la même fonctionnalité dans Aura par rapport à LWC. Grâce à la conversion de DreamHouse depuis Aura vers LWC, non seulement l'expérience de développement était beaucoup plus conforme aux normes et modèles actuels de développement frontal Web, mais les gains de performance étaient importants. Les mesures de laboratoire ont montré des gains de 2,4 % à 24,7 % pour la cache froide et des gains de 31,83 % à 63,32 % pour la cache chaude sur les deux mêmes pages.

Quelle infrastructure nos technologies de formulaire utilisent-elles ? En d'autres termes, quelles technologies de forme bénéficient de ces performances supérieures ?

• Les Formulaires dynamiques, qui sont intégrés dans les métadonnées des pages Lightning, reposent sur une fondation qui utilise la pile LWC, ce qui va nous permettre d'implémenter certaines fonctionnalités demandées depuis longtemps. En prime aux performances, les formulaires dynamiques utilisent un rendu progressif, ce qui améliore le temps de chargement des pages qui contiennent un grand nombre de champs.
• Les flux d'écran sont construits sur LWC, avec la plupart des composants prêts à l'emploi individuels désormais convertis en LWC, à l'exception de deux composants prêts à l'emploi : Chargement de fichier et image. L'équipe de Flow a converti le client d'exécution de flux en Composants Web Lightning ainsi que la plupart de ses composants, mais les clients doivent encore convertir leurs composants d'écran Aura en Composants Web Lightning. Non seulement cela, mais Salesforce prend en charge uniquement les composants LWC dans la nouvelle infrastructure de composants réactifs dans les flux d'écran. Il existe un excellent module Trailhead qui explique comment procéder: Composants Web Lightning pour développeurs Aura. Il va sans dire : Si vous envisagez d'élaborer un composant personnalisé pour un flux d'écran ou un autre conteneur, choisissez toujours LWC.
• Il existe quelques versions d'OmniStudio disponibles. Si vous êtes un client de longue date, vous utilisez peut-être Angular. Nous encourageons tous les nouveaux clients à commencer avec les Omniscripts et les FlexCards basés sur LWC, et les clients existants à migrer hors d'Angular.
• LWC est construit sur ... LWC bien sûr. C’est un freebie. 🤓

En tant qu'architecte, il est important de bien comprendre toutes les options qui s'offrent à vous et comment les appliquer à votre cas d'utilisation spécifique. Pour élaborer des formulaires sur Salesforce, les options vont du low-code (utilisation de Formulaires dynamiques dans le Générateur d'applications Lightning, de Flux d'écran dans Flow Builder et d'Omniscripts dans OmniStudio) au pro-code (utilisation de l'infrastructure LWC), avec une combinaison de flux d'écran ou d'Omniscripts et LWC au milieu. Tenez compte de ce guide et utilisez-le comme référence lorsque vous envisagez d'élaborer ou de reconcevoir des formulaires dans Salesforce. Si vous recherchez des conseils pour concevoir des formulaires rationalisés et utiles, consultez Salesforce Well-Architected: Engagé.

Aidez-nous à publier ce qui vous intéresse le plus : répondez à notre sondage pour nous faire part de vos commentaires sur ce contenu et nous dire ce que vous aimeriez voir ensuite.