Création de formulaires

Il existe plusieurs options pour élaborer des formulaires sur Agentforce 360 Platform, et elles couvrent un continuum allant des approches low-code aux approches pro-code. À une extrémité du continuum, les Formulaires dynamiques dans le Générateur d’applications Lightning et les flux d’écran dans Flow Builder peuvent être utilisés pour des solutions à faible code. D’autre part, l’infrastructure Lightning Web Component (LWC) est utilisée pour les solutions pro-code. Dans le continuum, les outils peuvent être fusionnés de plusieurs façons en utilisant des flux d’écran étendus par des composants Web Lightning et des formulaires destinés aux clients élaborés en utilisant Omnistudio.

Ce guide présente un cadre de décision et des conseils sur l’élaboration de formulaires pour des solutions d’interface utilisateur. Plus précisément, il utilise une douzaine de points d’exécution et de décision non fonctionnels afin de sélectionner correctement la meilleure technologie pour un cas d’utilisation donné.

• Lorsque vous élaborez des présentations Créer/Modifier/Afficher pour des pages Lightning, utilisez des Formulaires dynamiques. À l ’ avenir, nous recommandons d ’ utiliser des formulaires dynamiques dans le Générateur d ’ applications Lightning pour configurer des pages de détail d ’ enregistrement.

• Si vous devez élaborer, créer ou modifier un formulaire pour un seul objet, utilisez des pages Lightning et des formulaires dynamiques. C’est la méthode la plus simple pour élaborer des formulaires sur la plateforme Agentforce 360. Il fournit également des fonctionnalités supplémentaires (par exemple, le contrôle de la visibilité des champs).

• 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, utilisez un flux d’écran. Les flux d’écran fournissent une infrastructure de navigation linéaire pour l’orchestration de plusieurs formulaires. Vous pouvez utiliser des composants Web Lightning pour construire votre propre infrastructure de navigation entre les formulaires, mais nous recommandons de laisser Flow faire le travail afin de vous concentrer sur les formulaires eux-mêmes plutôt que sur l’état du formulaire.

• Si vous avez besoin d’une logique ou d’actions supplémentaires pour prendre en charge le formulaire, utilisez un flux d’écran, Omnistudio ou des composants Web Lightning. Chacun de ces outils offre différentes façons d’améliorer votre solution en l’élargissant au-delà de la création ou de la modification d’un seul enregistrement. Dans le cas présent, le terme plus peut désigner une logique avancée (par exemple branchement ou itération), ou des actions telles que l’intégration à des systèmes externes, l’envoi d’e-mails ou la transmission automatique de notifications à l’application mobile d’un utilisateur.

• Si vous avez des exigences UX sophistiquées ou si vous devez gérer dynamiquement plus que la visibilité de l’interface utilisateur, utilisez LWC ou Omniscript. Pour les exigences qui peuvent être satisfaites en utilisant des présentations basées sur des thèmes et des colonnes, vous pouvez élaborer vos formulaires directement dans un outil de création low-code. Cependant, un contrôle précis du style de votre formulaire nécessite la flexibilité de LWC. Si vous êtes un client de Industries (et que vous avez besoin d’une marque parfaite ou que vous avez des données hiérarchiques complexes), utilisez Omnistudio, qui permet d’élaborer des formulaires de niveau consommateur capables de gérer une logique métier complexe et des transformations de données.

• Si vous devez déployer une automatisation test, utilisez LWC. Vous pouvez écrire des tests unitaires pour n’importe quel Composant Web Lightning, quel que soit son emplacement d’incorporation. Cela permet de créer une stratégie de test plus robuste, qui peut inclure des tests en masse avec plusieurs enregistrements, ainsi que des tests négatifs.

• Vous n’êtes pas limité à des décisions « soit/ou ». Vous pouvez combiner plusieurs options pour trouver la meilleure solution pour vos cas d’utilisation (par exemple, si vous avez besoin du système de navigation intégré de Flow et de la flexibilité de style totale offerte par LWC, vous pouvez les utiliser ensemble).

Les outils suivants sont fréquemment utilisés pour implémenter et étendre les expériences de formulaire.

Le tableau ci-dessous présente les outils disponibles pour élaborer des formulaires via Salesforce, ainsi que leurs compétences requises et les considérations relatives aux licences.

Note : Nous approfondirons les fonctionnalités spécifiques prises en charge pour chaque outil, comment choisir entre les outils basés sur le clic et les outils basés sur le code, et quand les combiner dans une section ultérieure.

Il y a plusieurs points de décision à prendre en compte lors de la sélection de produits et d’outils. Le tableau ci-dessous présente divers points de décision et fournit des orientations générales.

Note : Dans les tableaux de comparaison de décision suivants, quelques valeurs sont associées à une paire outil-fonctionnalité :

• Disponible : L’outil/la fonctionnalité fonctionne avec des considérations de base.

• Non disponible : Il n’est pas prévu d’ajouter un support dans les douze prochains mois.

• Pas idéal : Cet outil/cette fonctionnalité peut fonctionner, mais ce n’est pas l’outil optimal.

• Non applicable : L’outil ne s’applique pas au cas d’utilisation particulier.

Utilisez ces scénarios pour comparer les choix d’outillage basés sur la portée, l’expérience utilisateur et les besoins opérationnels.

Si vous pouvez obtenir toutes vos entrées utilisateur à partir d’un formulaire à écran unique, commencez par les Formulaires dynamiques. Notez que les formulaires dynamiques dans les pages d’enregistrement peuvent utiliser la fonctionnalité Parcours pour prendre en charge les processus métiers intermédiaires.

• 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 en remplissant 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, choisir entre Flux, Omnistudio et Composant Web Lightning dépend de quelques questions supplémentaires :

• Vous pouvez afficher une barre de navigation en bas de votre formulaire ? Si l’expérience de navigation Flux d’écran et Omniscript fournit une expérience utilisateur indésirable, penchez-vous vers LWC.

• Que doit-il se passer derrière le formulaire ? Si vous souhaitez que le comportement soit configurable par un administrateur, utilisez un flux. Pour des relations complexes et multi-objets, utilisez Omniscript ou LWC.

Si vous choisissez Flow ou Omnistudio, il peut également être nécessaire d’élaborer un LWC 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 à un flux est nécessaire.

Navigation de style assistant

Par contre, si votre solution ressemble à un assistant (où l’utilisateur navigue entre plusieurs écrans), pensez à Flux ou Omnistudio. Les flux et Omnistudio contiennent 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 pour avancer, des actions pour reculer 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.

Omnistudio offre un avantage de navigation clé en fournissant des indicateurs de progression de la navigation standard qui exposent les étapes dans le formulaire. La vue de l’étape affiche automatiquement l’emplacement d’un utilisateur dans un formulaire à plusieurs étapes. Contrairement à Flux, il permet aux utilisateurs de passer d’un écran à l’autre en cliquant sur diverses étapes du formulaire.

Que vous élaboriez des formulaires à écran unique ou à écrans multiples, il est important de rationaliser vos formulaires afin de faciliter leur navigation pour vos utilisateurs.

Si vous incorporez un formulaire à une page d’enregistrement Lightning standard, tous les outils que nous comparons fonctionnent. Cependant, les Formulaires dynamiques ne sont actuellement disponibles que sur ordinateur de bureau. 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 doivent-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 activer 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 elle nécessite un contexte d’enregistrement, la fonctionnalité Formulaires dynamiques n’est prise en charge que dans les pages d’enregistrement Lightning. Cependant, les formulaires dynamiques ne sont pas pris en charge dans les pages Experience Cloud.

Vous pouvez élaborer des flux qui nécessitent un contexte d’enregistrement ou des flux qui fonctionnent globalement. En d’autres termes, vous pouvez incorporer des flux à divers emplacements. Pour des flux contextuels d’enregistrement, les emplacements peuvent inclure : Pages d’enregistrement Lightning, pages d’enregistrement Experience Cloud, actions spécifiques à un objet ou déploiements Actions et recommandations. Pour des flux globaux, les emplacements peuvent inclure : la barre d’utilitaires, d’autres pages Lightning ou Experience Builder, des snap-ins ou des applications externes. Actuellement, les flux ne sont pas pris en charge en tant qu’actions globales, mais vous pouvez insérer les flux dans un composant Aura pour contourner la situation.

Omnistudio permet d’élaborer des FlexCards et des Omniscripts composables que vous pouvez placer presque partout où vous pouvez placer un Flow, mais bien qu’ils soient composables, ils ne sont pas packagés.

LWC offre un haut degré de réutilisation pour créer des composants qui peuvent être associés à des cibles via des métadonnées dans Salesforce, des communautés et des projets open-source. Les composants LWC peuvent également être incorporés à votre propre site Web en utilisant Lightning Out 2.0.

Les composants LWC peuvent également lancer des flux avec le composant Lightning-Flow.

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

Actuellement, aucune des technologies de formulaire présentées dans ce guide n’est officiellement prise en charge dans les modèles Mobile SDK. Si Mobile SDK est essentiel à votre cas d’utilisation, nous recommandons d’élaborer votre formulaire en natif dans votre application mobile ou de construire une page Visualforce, tout en gardant le facteur de forme à l’esprit.

Les formulaires dynamiques sont parfaits si vous devez utiliser les valeurs de votre formulaire pour créer ou mettre à jour un enregistrement. Vous devez exploiter Flow, Omnistudio ou LWC pour des capacités extérieures à ce périmètre, notamment la création de couches 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 doivent être exécutées en arrière-plan ?

• Avez-vous besoin d’utiliser les valeurs d’un enregistrement associé ?

• 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 des e-mails et interagir avec des documents Quip, et vous n’avez pas à écrire de code pour l’une de ces opérations. LWC offre des interactions enrichies avec des enregistrements uniques et des objets associés via des adaptateurs wire qui interagissent avec l’API Interface utilisateur. LWC peut également interagir avec plusieurs enregistrements en utilisant le wire pour getListInfoByName.

Omnistudio utilise des procédures d’intégration et Data Mapper pour obtenir et transformer des données (externes et internes à Salesforce). Grâce à de nombreuses fonctions sans code, il excelle dans l’aplatissement et l’expansion des jeux de données avec divers niveaux de relations.

Flow, Omnistudio et LWC s’intègrent tous à Apex. Vous pouvez ainsi combler aisément les écarts au sein de la solution que vous choisissez (par exemple, si vous avez besoin de filtrer les enregistrements d’un LWC, vous pouvez utiliser l’adaptateur wire pour Apex afin de créer des requêtes SOQL complexes. Si vous êtes influencé par les récits basés sur le clic, pensez à utiliser Flow ou Omnistudio comme alternative viable à un contrôleur Apex pour vos besoins côté serveur.

Vous devez également déterminer 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 permet de combiner aisément les entrées de plusieurs formulaires (écrans de flux) et de les utiliser ultérieurement dans l’assistant (flux) pour effectuer certaines opérations. C’est exactement comme cela que nous recommandons de concevoir des flux. Exécuter des actions à la fin (au cas où les utilisateurs rebondissent entre les écrans pour changer leurs réponses).

Les transactions et les limites du gouverneur font partie intégrante de la plate-forme Agentforce 360. Si votre cas d’utilisation est assez simple, il peut ne pas être aussi important de contrôler la transaction où 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.

Voici quelques exemples :

• Rollback : Supposons que votre formulaire crée plusieurs enregistrements en arrière-plan. Si la création d’un troisième enregistrement échoue, les deux premiers enregistrements doivent-ils être annulés ? Si chacune de vos actions est indépendante les unes des autres, vous pouvez les exécuter en tant que transactions séparées. Cependant, s’ils sont dépendants les uns des autres (et que vous souhaitez que l’échec de l’un annule également les autres), vous devez les implémenter en tant que transaction unique. Si votre formulaire est dans Flux, vous pouvez utiliser l’élément Restaurer dans le chemin Défaut pour annuler votre transaction et garantir l’intégrité des données.

• Impact en aval sur les limites du gouverneur : Lorsque votre formulaire crée ou met à jour un enregistrement, il est important de prendre en compte les 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 peuvent se déclencher en fonction des modifications d’enregistrement proposées ?

  • Quel est l’impact de ces changements collectifs sur les limites du gouverneur consommées dans le cadre de cette transaction ?

  • Si une modification d’enregistrement particulière peut entraîner de nombreuses modifications en aval qui impactent vos limites, il peut être préférable d’isoler cette modification d’enregistrement dans sa propre transaction.

• Traitement par lot : Il peut être nécessaire de regrouper plusieurs mises à jour par lot (même dans un contexte d’interface utilisateur). 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 de mise à jour de 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 est toujours le début d’une nouvelle transaction nette.

Lorsque vous élaborez 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 comme des 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 d’entrée dans l’API.

3. L’API reçoit la requête et ouvre une connexion de transaction et de base de données. 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 d’écran ou d’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 (selon l’ordre d’enregistrement), 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 interagit.

7. Commencez depuis l’étape 1 et répétez le processus.

En d’autres termes, les écrans interrompent les transactions. Dans ce cas, toutes les actions en attente ou opérations DML sont validées, la transaction précédente est fermée et une nouvelle transaction commence. Notez que les éléments de conception spécifiques (opérations que vous regroupez dans une transaction donnée) vous appartiennent.

Voici quelques exemples :

• Au début, un flux collecte les entrées sur plusieurs écrans, puis exécute plusieurs actions dans une seule transaction.
• Le flux suivant effectue chaque opération dans une transaction séparée.
• Les flux peuvent également utiliser Restaurer les enregistrements pour vous permettre d’annuler une transaction complète si une seule opération échoue dans une série d’opérations de base de données. Supposons que vous avez un flux qui crée des enregistrements, met à jour des enregistrements, puis crée des enregistrements supplémentaires (illustré dans le flux suivant).

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éent et mettent à jour les enregistrements appropriés, mais pas le troisième. 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 collectivement (comme indiqué dans le flux final).

Note : Pour plus d’informations, consultez Flux dans les transactions et Traitement en masse des flux dans les transactions.

Votre capacité à contrôler la transaction depuis un Composant Web Lightning est basée sur les services sous-jacents que le Composant Web Lightning utilise pour exécuter 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 lors de la soumission du formulaire.

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 une seule transaction, envoyez les entrées à une technologie côté serveur (par exemple, un contrôleur Apex ou un flux). Notez que les règles de transaction habituelles de cette technologie restent applicables.

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 du code Apex personnalisé, Flow et Omnistudio ont des mécanismes de support déclaratif qui peuvent également s’intégrer à des API.

Si vous devez vous connecter à une API MuleSoft ou à un robot RPA, utilisez les Services MuleSoft, car ils génèrent un Service externe.

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

Pour toutes les autres instances, utilisez la fonctionnalité Appel externe HTTP (propulsé par les Services externes) dans Flux ou l’action HTTP dans Omnistudio.

Omnistudio offre un riche ensemble de capacités d’intégration qui peuvent appeler des systèmes externes en utilisant des procédures d’intégration pour transformer les données via Data Mapper.

Que vous utilisiez un code Apex personnalisé ou un service externe pour l’implémentation, un appel reste un appel externe.

Voici ce que vous devez savoir.

• Le traitement d’un appel externe peut prendre beaucoup de temps.

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

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

Notez que la principale limitation est le danger de laisser les données dans un état incohérent, qui se produit lorsque 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 schéma n’est pas autorisé en raison de la troisième considération mentionnée ci-dessus, qui existe pour les deux premières considérations.

Dans Flux, vous pouvez contourner cette limitation en rompant la transaction. Pour rappel, les écrans et les actions locales réintroduisent le contexte du navigateur. Vous pouvez utiliser des écrans et des actions locales lorsque vous travaillez avec des appels externes, mais nous recommandons d’activer le Contrôle des transactions dans les paramètres avancés invocables. Le Contrôle des transactions permet de terminer automatiquement la transaction avant qu’un appel externe soit passé. Pour activer le Contrôle des transactions, sélectionnez « Toujours démarrer une nouvelle transaction » dans la section Avancé de l’action invoquée. LWC simplifie l’impact des appels sur la transaction. En d’autres termes, effectuez vos opérations sur les données en utilisant le Lightning Data Service (LDS), puis utilisez un contrôleur Apex pour passer l’appel externe. Comme l’appel LDS est isolé dans sa propre transaction (distincte de l’appel externe Apex), cela vous protège contre l’incohérence des données qui en résulte.

Les formulaires dynamiques ne prennent pas en charge la réutilisation. Chacune est liée à 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 qui peuvent être utilisés à travers plusieurs composants, vous pouvez également appliquer des modèles de conception similaires lorsque vous créez des flux en exploitant la puissance des flux secondaires. Pour cela, enregistrez vos flux dans des compartiments modulaires plus petits, puis appelez-les à partir d’autres flux en utilisant l’élément Subflow. Si votre conception l’exige, vous pouvez créer un flux qui soit utile à la fois de manière autonome et en tant que sous-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, mais ils peuvent également fonctionner de façon interchangeable. Les FlexCards peuvent également ê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 également de capacités d’adaptation et de stabilité.

Toutes les technologies utilisées pour créer ou mettre à jour des enregistrements doivent respecter la validation au niveau du système, qu’il s’agisse de règles de validation classiques ou de validations personnalisées intégrées à un déclencheur Apex. Quelle que soit la technologie utilisée pour effectuer des modifications d’enregistrement, chaque modification doit passer par l’ordre d’enregistrement. Cela signifie qu’en plus des règles de validation, les modifications d’enregistrement sont également traitées par un certain nombre de flux avant ou après la sauvegarde, avant ou après les déclencheurs, règles d’escalade, règles d’attribution, etc.

Note : Si ce n’est déjà fait, consultez et ajoutez l’ordre d’exécution Apex aux favoris.

• Votre formulaire a-t-il d’autres exigences que la validation au niveau système ?

• Vous devez définir dynamiquement des champs obligatoires ou en lecture seule dans le formulaire ?

Généralement, les entrées d’un écran de flux ou d’une étape Omniscript ne sont pas 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 dans l’ordre d’enregistrement, ce qui signifie qu’elles passent par la validation au niveau système de l’objet.

Note : Les composants Flux d’écran ne prennent pas tous en charge la validation des entrées.

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

Le flux offre la flexibilité nécessaire pour personnaliser la validation de l’entrée de formulaire. Plusieurs contrôles sont effectués au niveau du client (par exemple, le marquage des champs obligatoires manquants et les contrôles de type de données, ainsi que les formules compatibles dans les règles de validation d’entrée). Comme niveau de sécurité supplémentaire, la validation de l’entrée est également évaluée sur le serveur. Lorsqu’un utilisateur clique sur Suivant, Flux envoie de nouveau les entrées au serveur pour validation. Si des entrées non valides sont renvoyées, la navigation est bloquée et l’erreur appropriée est affichée.

Le serveur valide les entrées en cochant :

• Le paramètre d’exigence de l’entrée, ou si la valeur saisie est compatible avec le type de données sous-jacent.

• La validation personnalisée de l’entrée. Vous devez fournir une expression de formule booléenne et un message d’erreur à afficher lorsque l’expression de formule n’est pas remplie.

• La validation personnalisée du composant sous-jacent. Si vous élaborez un composant Web Lightning personnalisé pour un flux, vous devez ajouter votre propre code de validation à la méthode validate().

Vous pouvez également fournir des alertes utilisateur accessibles via le composant Message dans des flux d’écran, mais cela n’empêche pas un utilisateur d’accéder à d’autres pages ou de passer à l’étape suivante dans un flux guidé. L’état Erreur dans le composant Message est préférable sur les écrans d’erreur dédiés qui sont déclenchés via un chemin de défaut lorsque la navigation est désactivée.

Omnistudio offre un traitement robuste des erreurs et des validations via l’action Définir l’erreur combinée à des vues conditionnelles et au composant Messagerie.

Pour LWC, la plupart des composants de base effectuent leurs propres validations côté client (par exemple, lightning-record-form respecte le caractère obligatoire au niveau système, mais pas au niveau de la page). Pour vos composants personnalisés, vous pouvez créer vos propres mécanismes de validation.

Notez que les champs qui nécessitent la saisie de données par les utilisateurs doivent être affichés au début de vos formulaires. Validez les entrées des utilisateurs côté client avant la soumission des formulaires (si possible).

Les formulaires statiques sont obsolètes. Aujourd’hui, l’attention s’est déplacée vers la mise à jour dynamique des formulaires avec les propriétés et les valeurs appropriées pour un utilisateur spécifique, à un moment spécifique, à un endroit spécifique. Examinons de plus près les possibilités offertes par les outils de création de formulaires Salesforce.

• Quels types d’interaction ou de condition doivent déclencher des réponses dynamiques dans votre formulaire ?

• Vous devez exécuter des opérations hors écran (en arrière-plan) pendant que votre formulaire est rempli ?

• Avez-vous besoin de définir des champs comme visibles, obligatoires, en lecture seule ou désactivés, ou de changer la mise en forme en fonction des entrées de formulaire ?

Les écrans réactifs activent l’interactivité des flux d’écran. La réactivité permet aux composants individuels d’un écran de flux de communiquer entre eux, ce qui augmente la puissance des flux d’écran.

Exécution d’opérations de données hors écran

Les flux d’écran fournissent 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 permettent de déclencher des flux lancés automatiquement lors d’une modification à l’écran ou lorsqu’un utilisateur clique sur un composant Bouton d’action. Vous pouvez mapper les résultats de flux lancés automatiquement avec le même écran, ce qui évite aux utilisateurs d’accéder à un autre écran.

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

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 en utilisant les fonctionnalités de visibilité des composants. Vous pouvez afficher ou masquer par déclaration des champs basés sur d’autres valeurs du formulaire, ou si l’utilisateur remplit le formulaire sur un appareil mobile.

• Les formulaires dynamiques contrôlent la visibilité en fonction des valeurs de champ d’enregistrement, 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 d’écran, ainsi que sur d’autres ressources remplies plus tôt dans le flux (par exemple, des formules ou des valeurs d’autres enregistrements).

  • Règles basées sur l’appareil : Ce n’est peut-être 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 remplit le formulaire en utilisant l’application mobile Salesforce.

  • Évaluer les autres ressources : Les références manuelles de variables et de formules sont évaluées uniquement sur le serveur. Cela signifie que la valeur de cette ressource lors de la restitution initiale de l’écran est celle qu’elle aura jusqu’à ce que vous accédiez à un autre écran. Pendant la navigation, l’exécution du flux soumet une requête au moteur de flux (le serveur) et renvoie les toutes dernières valeurs manuelles de variable et de formule. Si vous souhaitez que votre règle de visibilité soit mise à jour lorsque l’utilisateur traverse un seul écran (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 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. LWC fournit un contrôle complet et réactif de votre état d’entrée. Avec les composants Flux d’écran réactif, vous pouvez contrôler dynamiquement les attributs de composants (par exemple, lecture seule, désactivé et obligatoire) pour les composants standard qui le prennent en charge, tandis qu’Omnistudio prend en charge tout le spectre 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), utilisez LWC à court terme, car vous avez le contrôle total. Cela est particulièrement vrai si vous avez des exigences sur mesure pour gérer onblur ou onclick.

LWC réactifs dans les flux d’écran

Si vous élaborez des composants Web Lightning capables de réagir et de modifier d’autres composants dans un flux d’écran, consultez le guide LWC Best Practices for Screen Flows pour vous assurer que vos composants s’intègrent au moteur d’exécution du flux et fonctionnent comme prévu.

Pour des événements personnalisés, si certaines de vos entrées (ou le formulaire complet) doivent communiquer avec un autre élément de 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 le service Lightning Messaging.

• Si le service de messagerie Lightning n’est pas pris en charge pour votre conteneur cible, utilisez le module pub/sub.

• Pour des informations plus détaillées, consultez Communiquer avec des événements et Communiquer à travers le 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, il est important de s’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 impliquer d’utiliser des modèles standard fournis par Salesforce ou de créer une feuille de style CSS personnalisée qui utilise chaque pixel de la conception pour améliorer la présentation.

Les administrateurs peuvent configurer un ensemble limité de remplacements de style d’écran et de composant (par exemple, couleurs, bordures et apparences de bouton), pour le conteneur d’écran ou pour des composants individuels. Ces remplacements sont appliqués après les thèmes et la personnalisation de la marque, ce qui permet aux concepteurs d’ajuster visuellement les paramètres sans impacter le reste de l’application.

Les remplacements de style sont conçus pour des exceptions visuelles localisées (par exemple, mettre en évidence un écran de confirmation ou souligner un appel à l’action (CTA) spécifique) ; ils ne sont pas un système de style complet. Ils ne fournissent pas de contrôle au niveau CSS et ne sont pas conçus pour être réutilisés à travers les écrans ou les flux.

D’un point de vue architectural, le style devrait suivre cet ordre de priorité :

1. Thèmes et marque : Thèmes Lightning, ensembles de marque Experience Builder ou thématisation de site LWR

2. Remplacements de style de flux : Ajustements ciblés de l’écran ou du composant

3. Composants personnalisés (LWC) : lorsqu’il est nécessaire d’avoir un contrôle pixel-perfect ou des modèles de conception réutilisables

L’utilisation de thèmes et de systèmes de conception permet de garantir un style cohérent, évolutif et facile à gérer au fil du temps.

• Quel est le niveau de sophistication de votre style et CSS ?

• Avez-vous besoin d’un style personnalisé, parfait en pixels ou de thèmes standard ?

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

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

Les équipes qui maîtrisent CSS ont plusieurs options :

• Les flux et les composants Web Lightning héritent de jetons de conception standard.

• Les Omniscripts et les FlexCards prennent en charge le système de conception personnalisable via Newport.

• Avec LWC, vous pouvez écrire vos propres composants et contrôler entièrement leur HTML et CSS.

Dans la mesure du possible, nous recommandons d’utiliser des thèmes et des systèmes de conception pour garantir une présentation cohérente de tous vos contenus.

Note : Vous pouvez incorporer des composants Lightning dans des flux. Si vous avez besoin d’un contrôle parfait de la présentation de votre formulaire, mais que vous souhaitez également utiliser les autres avantages des flux (par exemple, 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é.

• Comment structurer les présentations de formulaire pour optimiser l’expérience utilisateur ?

• Comment présenter aux 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 qui peuvent être divisées en sections individuelles dans les champs. Ces sections peuvent être placées dans des composants (par exemple, des onglets et des accordéons) pour créer des présentations organisées et faciles à utiliser.

Les flux peuvent également être restitués en utilisant le composant Section. Vous pouvez ajouter jusqu’à quatre colonnes et un nombre illimité de sections à l’écran de flux. Le composant Sections est également réactif à la largeur de l’écran. Par conséquent, il fonctionne également sur les écrans plus petits. Il permet d’appliquer une visibilité conditionnelle à l’ensemble de 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-record-[edit|view]-form et le champ lightning-[input|output]-field associé pour contrôler la présentation. Les seules restrictions de présentation proviennent de HTML et CSS. Le composant Lightning-record-form 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 également à deux colonnes dans le composant).

Si votre formulaire doit être accessible par des utilisateurs de différentes régions ou qui parlent différentes langues, vous devez vous assurer que l’outil que vous utilisez pour l’élaborer répond à vos exigences de traduction.

Note : Pour les 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 localisez des champs personnalisés, les Formulaires dynamiques respectent les étiquettes traduites. Les formulaires dynamiques respectent également les étiquettes personnalisées attribuées aux étiquettes et aux attributs des composants dans le Générateur d’applications Lightning.

Flux prend en charge la traduction des étiquettes accessibles aux utilisateurs pour tous les composants d’écran standard et personnalisés via le Workbench de traduction.

Vous pouvez localiser des étiquettes, un texte d’aide et des messages d’erreur dans les composants d’écran suivants :

• Texte
• Zone de texte longue
• Numéro
• Devise
• Case à cocher
• Cases d’option
• Liste de sélection
• Liste à sélection multiple
• Mot de passe du groupe de cases à cocher
• Date
• Date/heure

Il n’y a pas de prise en charge de la traduction intégrée pour les actions prêtes à l’emploi (par exemple, Envoyer un e-mail ou Publier dans Chatter), mais il existe une solution de contournement. Si vous utilisez une étiquette personnalisée pour définir les étiquettes traduites, vous pouvez référencer cette étiquette personnalisée dans l’action ou le composant en la configurant dans Flow Builder. Pour cela, vous devez créer une formule de flux qui référence l’étiquette personnalisée, puis référencer cette formule aux emplacements appropriés de votre flux.

Les Omniscripts utilisent des étiquettes personnalisées pour les traductions. Pour plus d’informations, consultez ce document d’aide pour vous assurer que vos Omniscripts sont prêts pour le multilinguisme.

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 sont configurés dans le Workbench de traduction (par exemple, lightning-record-form).

Si vous devez introduire de nouvelles étiquettes traduisibles dans votre code, les étiquettes personnalisées sont la solution idéale. Déclarez l’étiquette personnalisée dont vous avez besoin, puis importez-la dans votre composant depuis le module d’étendue @salesforce/label.

Utilisez cette section pour évaluer les contraintes de sécurité, de qualité et opérationnelles avant l’implémentation.

La sécurité est un sujet complexe, et quand il s’agit d’élaborer des formulaires, il y a un certain nombre de considérations qui ne sont peut-être pas évidentes. 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. Pour plus d’informations sur ce type de documentation, consultez le modèle de politique de sécurité Well-Architected de Salesforce.

• 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 programme est exécuté dans le contexte utilisateur, Salesforce applique une série de contrôles d’accès, qui comprennent 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 en utilisant votre formulaire, mais pas via un autre formulaire ou une autre interaction ? C’est là que le Contexte système intervient !

Contexte système permet d’augmenter les autorisations d’un utilisateur pendant la durée de la session (par exemple, l’utilisateur n’a pas besoin 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.

Le Contexte système doit être utilisé uniquement lorsque cela est absolument nécessaire. Lorsqu’un formulaire est exécuté dans le contexte système, chaque opération CRUD contourne les composants de sécurité et de partage au niveau de l’objet et du champ. De plus, le contexte système n’a aucune incidence sur la personne que Salesforce considère comme l’acteur (le nom affiché dans le champ Dernière modification par). Pour chaque opération que votre formulaire effectue (par exemple, une mise à jour de requête), l’acteur est l’utilisateur actuel (même si le formulaire est exécuté dans un contexte différent).

Note : 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 décider si le flux doit accorder l’accès à toutes les données ou s’il doit appliquer l’accès au niveau de l’enregistrement.

• 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 utilisateur, utilisez 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 (par exemple, Référence) ne peuvent pas fonctionner dans le contexte système.

• Si votre flux appelle des actions Apex, d’autres nuances sont impliquées.

  • Si la classe Apex est définie sur le partage hérité, elle sera exécutée dans le contexte système avec partage, quelle que soit la méthode utilisée pour définir le flux.

  • Si la classe n’a pas de déclaration de partage explicite, elle est exécutée dans le contexte système sans partage, quelle que soit la configuration du flux.

  • Si la classe est définie sur avec partage ou sans partage, elle remplace le contexte du flux.

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

Si vous exécutez un flux dans le contexte système sur un site Experience Cloud (en particulier s’il n’est pas authentifié), stockez 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 par les outils de développement du navigateur. Malgré vos intentions, les champs peuvent être disponibles pour les utilisateurs d’Experience Cloud. Pour vous assurer que seuls les champs corrects sont exposés lorsque le Contexte système est activé, spécifiez ces champs spécifiques dans vos éléments Obtenir des enregistrements.

Note : 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 Procédures d’intégration, aux Mappeurs de données et aux appels de méthode Apex via les outils pour développeur du navigateur. Lorsque vous utilisez Omniscript, il est important 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 pour toutes les méthodes Apex exposées via une annotation @InvocableMethod.

Assainir les entrées

Pour protéger votre organisation contre les mauvais acteurs, utilisez la désinfection des entrées. Supposons que vous avez une entrée dans un formulaire accessible au public qui peut être mappé avec un champ Texte enrichi au sein de votre organisation. Vous pouvez activer l’automatisation qui supprime tout code HTML susceptible de masquer des URL malveillantes.

Il n’est pas idéal d’implémenter la désinfection au niveau du formulaire, car vous pouvez avoir n’importe quel nombre de sources qui écrivent dans ces champs. Pour lutter contre ce problème, créez un flux de mise à jour rapide des champs (avant l’enregistrement) ou utilisez un déclencheur Apex existant pour retirer ou modifier tout code HTML éventuellement saisi dans le formulaire.

• Autorisez l’exécution des flux dans leur contexte par défaut (sauf si vous devez élever l’accès de l’utilisateur actuel à une opération spécifique).

• Évitez d’exécuter des flux dans le contexte système pour les utilisateurs invités. Créez des ensembles d’autorisations avec un accès limité aux champs et attribuez-les au profil de l’utilisateur invité Experience Cloud.

• Lors de l’interrogation d’enregistrements dans des flux Exécuter le contexte système sur des sites Experience Cloud, stockez uniquement les champs dont vous avez besoin dans l’élément Obtenir des enregistrements ou des actions invocables.

• Si un flux exécute diverses opérations, qui ne nécessitent pas d’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 incorporez un formulaire à une page Web externe, il peut être nécessaire de le mapper avec des champs de texte enrichi afin d’éviter les attaques potentielles par hameçonnage. Pour ce faire, désinfectez les entrées des utilisateurs afin de retirer le code HTML en utilisant un flux de mise à jour de champ rapide ou un déclencheur Apex.

• Les Omniscripts, les FlexCards et les Composants Web Lightning sont exécutés par défaut dans le contexte de l’utilisateur.

• Les composants Web Lightning sont exécutés par défaut dans le contexte de l’utilisateur.

• Les flux sont exécutés dans le contexte de l’utilisateur, mais vous pouvez le remplacer en utilisant un contrôleur Apex.

• Les opérations exécutées dans l’API UI sont exécutées dans le contexte de l’utilisateur.

• Les opérations exécutées avec un contrôleur Apex dépendent de la classe spécifique. Pour exécuter ces opérations en mode système, définissez la classe Apex sur avec partage ou sans partage.

Si vous devez contrôler qui peut accéder à un formulaire, vérifiez 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 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 des pages Visualforce). Les flux ne sont pas restreints par défaut, ce qui signifie que tout utilisateur disposant de l’autorisation utilisateur Exécuter des flux peut y accéder.

Si vous utilisez Omnistudio, vous pouvez configurer un vérificateur d’autorisations de classe Apex qui exige que les utilisateurs aient explicitement accès à la classe Apex qui administre les actions distantes depuis Omniscript, Flexcard, Classic Card, ou les API REST.

Note : Les contrôles d’autorisation de classe Apex s’appliquent uniquement aux classes Apex. Il est également conseillé de définir des autorisations au niveau du profil pour les Procédures d’intégration et les Mappeurs de données.

• Si vous exposez un flux à des utilisateurs invités, vous devez accorder uniquement l’accès au profil utilisateur invité aux flux dont ils ont absolument besoin. Il est possible d’ajouter Exécuter des flux à des profils utilisateur invité, mais cette pratique peut s’avérer risquée.

• Soyez prudent en utilisant des flux qui fonctionnent dans le contexte système. Vous devez limiter ces flux à un groupe particulier d’utilisateurs, car ils ont moins de freins et de contrepoids en place pour protéger vos données.

• Assurez-vous que tout Omniscript qui exécute Apex dans une communauté d’utilisateurs invités a avec partage répertorié dans la définition de classe Apex.

• Pour les profils utilisateur invité, attribuez uniquement les classes Apex que vous souhaitez autoriser les utilisateurs invités à appeler. En suivant cette pratique, il permet d’éviter 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 actuel afin de vérifier s’il dispose d’une autorisation standard ou personnalisée particulière. Vous pouvez importer des autorisations Salesforce à partir des modules d’étendue @salesforce/userPermission et @salesforce/customPermission directement dans JavaScript. Vous pouvez également utiliser Apex pour vérifier les autorisations.

Les composants Web Lightning ne sont disponibles à un emplacement donné qu’après avoir été ajoutés en tant que cible valide (par exemple, vous pouvez rendre un composant disponible dans les pages d’enregistrement et non disponible en tant qu’élément de la barre d’utilitaires).

Une fois activé, un flux d’écran est disponible à tous les emplacements pris en charge par les flux d’écran. Flow Builder prend en charge plusieurs types de flux qui ont des écrans. Le type le plus important 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 les flux Field Service Mobile). Cela est similaire aux flux de demandes de contact, qui sont pris en charge uniquement dans Experience Cloud.

Quel que soit le type de flux, la personne qui crée le flux n’a aucun contrôle sur l’emplacement d’incorporation du flux. Les flux sont disponibles à chaque emplacement où ce type de flux spécifique est pris en charge.

Si vous utilisez Salesforce Industries, une légère mise en garde s’applique à Omniscript.Vous ne pouvez pas spécifier une cible pour un Omniscript, mais vous pouvez spécifier une cible pour les FlexCards que vous souhaitez incorporer.

Salesforce offre plusieurs outils d’automatisation des tests de bout en bout (par exemple, consultez Salesforce UTAM) qui permettent de simuler l’interaction d’un utilisateur avec vos formulaires. Vous pouvez écrire des tests pour n’importe quelle interface utilisateur standard ou personnalisée, y compris les pages Lightning et les flux d’écran.

Note : Ces types de test ne peuvent pas vérifier les sorties des méthodes exécutées. Gardez cela à l’esprit lorsque vous configurez vos exigences d’automatisation des tests d’interface utilisateur.

• Avez-vous besoin de tests automatisés pour vos formulaires ?

• Quels types de test envisagez-vous d’effectuer ?

• Quel niveau de granularité est nécessaire pour les automatisations de test ?

Considérer les exigences d’automatisation des tests d’interface utilisateur

Les tests unitaires fournissent une automatisation et une validation précises qui s’alignent sur les systèmes et les outils CI/CD standard de l’industrie, qui testent la logique métier, les contrôles JavaScript et les sorties de composants spécifiques. Si vous choisissez une approche low-code, vous ne pourrez pas créer vous-même des tests. Cependant, Salesforce teste rigoureusement toutes les offres de bout en bout.

Si les méthodes de votre composant sont complexes, vous pouvez les envoyer par SMS individuellement en les plaçant dans des fichiers JavaScript dédiés. Cela permet de les importer dans un LWC, puis dans un test Jest (par exemple, import { sort } from ‘c/utils’;).

Vous pouvez utiliser une solution sans code d’un éditeur de logiciels, élaborer une solution de test-automatisation personnalisée ou utiliser une infrastructure de test open-source (par exemple, Selenium WebDriver ou WebdriverIO) pour l’automatisation de bout en bout. Ces solutions sont valables pour toutes les interactions de l’interface utilisateur de Salesforce (par exemple, un Formulaire dynamique dans une page Lightning, un Flux d’écran dans une barre d’utilitaires ou un Composant Web Lightning dans un flux d’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 suivre le nombre de fois que votre formulaire a été rempli jusqu’au temps que l’utilisateur moyen passe à remplir le formulaire avant de soumettre ses informations. Il est important d’identifier vos indicateurs de performance clés à suivre avant de choisir un outil.

• Avez-vous besoin de suivre l’utilisation du formulaire ?

• Quels indicateurs de performance clés peuvent déterminer si le formulaire est utilisé efficacement ?

Si vous devez suivre l’utilisation et l’adoption générales du formulaire, utilisez des outils à faible code. Les formulaires dynamiques et les flux d’écran sont suivis via des rapports personnalisés prêts à l’emploi. Cependant, les rapports de suivi de flux d’écran offrent une précision supplémentaire. Si vous devez suivre l’utilisation des composants Web Lightning, la disponibilité prête à l’emploi dépend de l’emplacement où vous utilisez les composants Web Lightning. S’il se trouve dans une page Lightning, tous les éléments de suivi de l’utilisation des pages Lightning disponibles s’appliquent également à votre Composant Web Lightning. Cela est également vrai pour les composants Web Lightning incorporés à des flux.

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

Les flux peuvent vous aider à suivre l’adoption de formulaires spécifiques. Utilisez l’exemple de rapport de flux : Flux d’écran pour répondre à ces types de questions :

• Quel est le taux de complétion de ce formulaire ? Est-il bien adopté actuellement ?

• Combien de temps faut-il aux utilisateurs pour remplir ce formulaire ?

• Sur quel écran les utilisateurs passent-ils le plus de temps à compléter ?

• À quelle fréquence les utilisateurs accèdent-ils aux écrans précédents ?

• À quelle fréquence les erreurs se produisent-elles ?

Si le rapport standard ne répond pas à vos besoins, vous pouvez le cloner et apporter des modifications ou Build Your Own rapport à partir de zéro en utilisant le rapport Screen Flows.

Si vous utilisez l’exécution Omniscript basée sur un package, vous pouvez également utiliser le Omnistudio for Vlocity Tracking Service. Ce service suit tous les types d’événement (vous pouvez par exemple suivre le temps nécessaire pour suivre les étapes dans un Omniscript, ce qui aide à identifier les améliorations du processus).

Note : Il n’existe pas d’option prête à l’emploi pour suivre un Composant Web Lightning qui n’est pas incorporé à un flux d’écran, un Omniscript ou une page Lightning, mais vous pouvez élaborer une solution personnalisée en utilisant Apex.

Vous connaissez peut-être l’utilisation d’ensembles de modifications ou du DevanOps Center pour déployer votre solution dans des environnements de test ou en production. Ces options de déploiement prennent entièrement en charge les formulaires dynamiques, les flux et les LWC. Cependant, Omnistudio nécessite un outil séparé, le IDX Workbench.

• Comment comptez-vous déployer le formulaire ?

• Le formulaire doit-il être 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, consultez Formulaires dynamiques, flux et composants Web Lightning. Notez qu’Omnistudio ne prend pas en charge l’empaquetage.

Ce guide a pour but de vous montrer les fonctionnalités et les niveaux de personnalisation disponibles via les formulaires dynamiques, les flux d’écran, Omnistudio et LWC. Voici une vue d’ensemble.

• En ce qui concerne la création de formulaires, LWC est l’option la plus robuste et personnalisable, mais il offre le moins de garde-fous. C’est pourquoi il est crucial d’élaborer vos composants en gardant à l’esprit la sécurité et l’évolutivité.

• Les formulaires dynamiques sont l’option la moins flexible, mais les possibilités de faux pas sont beaucoup moins nombreuses.

• Flow et Omnistudio tombent légèrement au milieu. Ils sont plus puissants que les formulaires dynamiques, mais ils ne sont pas tout à fait au niveau LWC. Cependant, ils ont moins de garde-fous que les Formulaires dynamiques et sont plus difficiles à briser qu’un code personnalisé.

Plusieurs outils peuvent répondre à vos besoins. Dans ce cas, la décision dépend de l’outil le plus adapté à votre équipe. Pour plus d’informations sur les aspects supplémentaires à prendre en compte, consultez les Architect Decision Guides ci-dessous.

• Lorsque vous comparez des outils, il est important d’évaluer l’expertise de votre équipe par rapport à chaque outil ?
• Combien de vos développeurs maîtrisent LWC ou JavaScript ?
• Votre équipe compte-t-elle des développeurs experts en Flow Builder ou qui ont exprimé leur intérêt pour en savoir plus ?

Nous n’entrerons pas dans les détails spécifiques, mais voici un peu plus d’informations sur le lien entre ces outils spécifiques et les évaluations que nous avons couvertes jusqu’à présent.

Délégation de livraison

Notez que même si certaines de vos exigences nécessitent LWC, il n’est pas nécessaire d’élaborer la solution complète en utilisant LWC. Il est important de déterminer comment élaborer votre solution de façon modulaire. Pour ce faire, vous devez identifier les pièces qui nécessitent un Composant Web Lightning codé et celles qui n’en nécessitent pas. Les parties qui ne nécessitent pas de LWC doivent être construites en utilisant une solution à faible code.

En ce qui concerne Flux et Composants Web Lightning, divers composants (par exemple, Composants d’écran réactifs et Flux d’écran) peuvent être synchronisés sur le même écran afin de libérer de nouveaux 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 l’équipe. Cela permet aux développeurs de gagner du temps en utilisant une combinaison de composants Flux standard et personnalisés pour obtenir un dynamisme de forme, ce qui leur donne plus de temps pour se concentrer sur la résolution de nouveaux défis. Avec l’introduction 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 formulaires.

Propriété et maintenance à long terme

Si vous créez un formulaire à plusieurs étapes, commencez par Flow ou une combinaison de Flow et de LWC. Si l’équipe qui gère le formulaire est une équipe à faible code, assurez-vous que la solution est aussi configurable et extensible que possible pour votre audience cible. Pour améliorer la stabilité et la maintenabilité, il est important d’organiser votre solution en unités composables, quel que soit l’outil choisi.

Les considérations relatives aux performances liées aux formulaires dynamiques, aux flux d’écran, à Omnistudio ou aux composants Web Lightning sont basées sur l’infrastructure dans laquelle les technologies sont hébergées. Les technologies basées sur LWC ont tendance à dépasser celles basées sur Aura. Grâce à plusieurs fonctionnalités principales implémentées nativement dans les moteurs Web (plutôt qu’en JavaScript via des abstractions d’infrastructure), le LWC offre des performances améliorées.

Comment exploiter ces avantages en termes de performance pour nos technologies de formulaire chez Salesforce ? Examinons de plus près.

• Les formulaires dynamiques (intégrés dans les métadonnées de page Lightning) reposent sur une base LWC, ce qui nous permet de mettre en œuvre plusieurs fonctionnalités tant attendues. Pour plus de performance, les formulaires dynamiques utilisent le rendu progressif, qui accélère le chargement des pages contenant un grand nombre de champs.

• Les flux d’écran reposent sur LWC. La plupart des composants individuels prêts à l’emploi ont été convertis en Composants Web Lightning, à l’exception des composants Chargement de fichier et Image. L’équipe de Flow a converti le client d’exécution de flux en Composants Web Lightning (et la plupart de ses composants), mais les clients doivent encore convertir leurs composants d’écran Aura en Composants Web Lightning. Notez que Salesforce prend en charge uniquement les composants LWC au sein du framework Composant réactif dans les flux d’écran. Pour plus d’informations, consultez le module Trailhead Lightning Web Components for Aura Developer. Si vous envisagez d’élaborer un composant personnalisé pour un flux d’écran (ou tout autre conteneur), choisissez LWC !

• Il existe plusieurs versions d’Omnistudio disponibles. Si vous êtes un client de longue date, vous utilisez peut-être Angular. Nous encourageons tous les nouveaux clients à utiliser des Omniscripts et des FlexCards basés sur LWC. Nous encourageons également les clients existants à migrer hors d’Angular.

• LWC est construit sur LWC.