• Accueil / Salesforce / Le guide ultime…
, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Le guide ultime des meilleures pratiques et normes de flux24 minutes de lecture


Il n’y a aucun moyen de contourner cela : Salesforce Flow est les outil d’automatisation du futur. Flow n’est pas seulement un « outil d’administration » : c’est le Saint Graal du développement déclaratif qui unit les développeurs ET les administrateurs en permettant l’utilisation de Lightning Web Components (LWC) et d’Apex, et en laissant l’administrateur tout orchestrer au même endroit. Nous commençons à voir une collaboration unique entre les administrateurs et les développeurs, les deux parties apprenant quelque chose sur le développement et l’administration.

Dans ce blog, nous discuterons des meilleures pratiques, des « pièges » et des conseils de conception pour vous assurer que vos flux évoluent avec votre organisation.

1. Documentez vos flux !

Documenter votre flux permet à la personne suivante, ou à la future version oublieuse de vous-même, de comprendre l’objectif global du flux. Les concepteurs de flux ne créent pas de solutions à partir de rien – nous avons besoin d’une analyse de rentabilisation pour résoudre des problèmes difficiles, et disposer de ces fils d’Ariane est essentiel pour maintenir l’automatisation à long terme.

Décrire le but du flux

Remplissez ce champ de description ! Quel problème votre flux résout-il ? Assurez-vous d’inclure ce que fait votre flux, les objets que votre flux touche et d’où il est invoqué (comme la mise en page à utiliser s’il s’agit d’un flux d’écran, le processus Process Builder à utiliser s’il s’agit d’un flux lancé automatiquement, etc.). Mieux encore, si vous pouvez parler ou mentionner où ce flux se connecte au processus métier et quels groupes il touche afin que la personne suivante puisse lui poser des questions. Vous avez un JIRA ou un Story ID pour le lier à une Story ? Collez-le dans la description!

Garantir un nommage cohérent entre les éléments et les variables

Respectez les conventions de nommage lors de la création de variables et d’éléments dans Flow. Incluez dans la description de la variable ce que vous capturez. Un peu de travail en amont sera très utile pour le futur « vous » ou quelqu’un d’autre qui héritera du flux. Il n’y a pas de bonne ou de mauvaise façon de le faire ; il suffit de le garder cohérent dans le flux. Une convention de nommage populaire s’appelle Camel Case. Découvrez ce chouette Article Wiki du serveur Discord de Salesforce Exchange sur les suggestions de noms de flux.

Documentez chaque étape

Assurez-vous d’écrire de courts textes de présentation à chaque étape et expliquez ce qu’est chaque élément de Flow et son objectif. Cela permettra à tout membre de l’équipe de reprendre le travail si nécessaire. Ceci est particulièrement critique lorsque vous utilisez une solution de contournement pour résoudre une limitation de flux, exécuter une fonction plus avancée ou appeler un invocable Apex.

2. Exploitez le pouvoir des actions invoquées

Nettoyez les flux inefficaces avec des actions invoquées – n’ayez pas peur d’utiliser du code réutilisable pour créer des flux agréables, propres et présentables. Autrefois, vous pouviez appeler Apex à partir de Flow, mais vous deviez pratiquement l’utiliser pour cet objet ou ce type de données. Ces jours sont révolus, Flow prenant désormais en charge les entrées et sorties génériques. Le code générique utilisé dans les actions invocables amplifiera vos capacités de flux à tous les niveaux : utilisez une action pour autant de flux que vous le souhaitez !

, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Flow est fantastique mais a ses limites, en particulier autour des requêtes, des gros volumes de données et du travail avec des collections. Vous vous retrouvez à créer des boucles sur des boucles, puis des boucles plus imbriquées, ou à atteindre les limites d’exécution des éléments ? Il est temps pour Apex réutilisable de faire le gros du travail pour vous.

Noter: Il existe deux grands référentiels pour les actions appelées par Flow : le Bibliothèque de composants d’automatisation et Non officielSF.

3. Utiliser des sous-flux pour des moyens plus propres, réutilisables et évolutifs de gérer les flux

Prenez ce flux comme exemple du moment où vous devriez commencer à vous demander : « Dois-je utiliser un sous-flux ? »

, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Voici quelques cas d’utilisation classiques pour lesquels vous devriez envisager un sous-flux :

  • Réutilisation: Si vous faites plusieurs fois la même chose dans votre flux, ou si vous faites la même chose que vous avez fait avec un autre flux, appelez un sous-flux pour le faire pour vous. Le monde du développement appelle ces classes « Helper ».
  • Processus/sous-processus complexes : Si votre flux implique plusieurs processus et une logique de branchement, utilisez un flux principal qui lance d’autres flux secondaires. Exemple:
    • « Gérer les données de contact » : flux d’écran principal qui lance divers processus déconnectés :
      • Contact associé aux entreprises
      • Vérifier les données de contact
      • Gérer les associations de contacts
  • Chaos organisationnel : Si votre flux ressemble à celui ci-dessus, vous avez probablement besoin d’un sous-flux (ou de plusieurs) juste pour comprendre comment tout se connecte et pour donner un sens au processus plus vaste.
  • Gestion des autorisations : Disons que vous avez un flux d’écran en cours d’exécution dans le contexte de l’utilisateur, mais que vous devez récupérer un objet système auquel l’utilisateur n’a pas accès. Utilisez un sous-flux ! En utilisant un sous-flux avec des autorisations élevées, vous pouvez accorder temporairement à cet utilisateur ce dont il a besoin pour continuer le flux.

Avantages des sous-flux :

  • Faire des changements une fois que au lieu de 10 endroits différents.
  • Profitez de flux clairs, concis et mieux organisés.
  • Conservez un emplacement unique pour les comportements à l’échelle de l’organisation, comme l’envoi d’un e-mail d’erreur cohérent ou l’affichage du même écran d’erreur à travers les flux (lors de la transmission de la variable $Flow.FaultMessage).

Considérations avec les sous-flux :

  • Pas encore pris en charge dans les flux déclenchés par enregistrement.
  • Nécessite plus de collaboration et de tests entre les groupes si des modifications doivent être apportées au sous-flux.
  • Le débogage peut être délicat avec les sous-flux. Lorsque vous commencez à utiliser des composants Lightning et des actions Apex, vous n’obtenez pas toujours des erreurs détaillées si l’erreur s’est produite dans un sous-flux.
  • Il y a une surcharge UX associée à l’excès avec les sous-flux – n’allez pas faire trop beaucoup.

4. Ne surchargez pas les flux avec une logique codée en dur

Abstraction logique

Un excellent moyen de ralentir votre processus de développement et de réduire l’agilité de votre équipe consiste à coder en dur toute votre logique à partir des flux. Dans la mesure du possible, vous devez stocker votre logique au même endroit afin que d’autres outils d’automatisation tels qu’Apex, les règles de validation et d’autres flux puissent également en bénéficier. Par cette excellente présentation en 2018 sur la chaîne YouTube Salesforce Admin, vous devriez envisager d’utiliser des métadonnées personnalisées, des paramètres personnalisés ou des étiquettes personnalisées dans vos flux dans les scénarios suivants :

  • Consolidez les données d’application ou d’organisation référencées à plusieurs endroits.
  • Gérer les mappages (par exemple, mapper un état à un taux de taxe ou mapper un type d’enregistrement à une file d’attente).
  • Gérez les informations qui sont sujettes à changement ou qui changeront fréquemment.
  • Stockez le texte fréquemment utilisé, comme les descriptions de tâches, les descriptions Chatter ou le contenu de notification.
  • Stockez les variables d’environnement (URL ou valeurs spécifiques à chaque environnement Salesforce).

Vous pouvez utiliser des éléments tels que des étiquettes personnalisées si vous souhaitez stocker des valeurs simples telles que « X jours », des identifiants de propriétaire d’enregistrement ou des valeurs susceptibles de changer à l’avenir.

Pour vous donner une idée de la propreté des flux basés sur les métadonnées personnalisées, jetez un œil à l’avant et à l’après de ce flux de cas après enregistrement qui mappe les types d’enregistrement avec les files d’attente. La solution a utilisé des enregistrements de métadonnées personnalisées qui stockent un nom de développeur de file d’attente, un nom de développeur RecordType et le champ Département pour mettre à jour le dossier de manière dynamique.

Avant la logique basée sur les métadonnées personnalisées

, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Après la logique basée sur les métadonnées personnalisées

, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Flux d’écran pilotés par les données

Si vous constatez que votre équipe construit 20 à 30 (ou plus) écrans avec une logique et un contenu en constante évolution, vous aurez peut-être besoin d’un modèle de conception d’écran dynamique basé sur des données d’enregistrement.

Regarde ça excellent article sur UnofficialSF écrit par Alex Edelstein, vice-président des produits chez Salesforce, sur la façon dont vous pouvez créer un flux équivalent à 500 écrans en utilisant uniquement des enregistrements d’objets personnalisés (DiagnosticNode/DiagnosticOutcome).

Autres liens utiles sur Flow et la logique métier :

5. Ne faites pas ces erreurs courantes de « constructeur »

Vérifier les collections nulles/vides

Le flux est essentiellement un codage déclaratif, ce qui signifie que les garde-corps sont éteints ! Vous devez planifier chaque scénario lors de la création de votre flux. Cela signifie planifier les cas où ce que vous recherchez pourrait ne pas exister !

Ayez toujours une décision après un élément Lookup/Get pour vérifier l’absence de résultats si vous prévoyez d’utiliser les résultats plus tard dans votre flux. Directement après la recherche, ajoutez un contrôle de décision « Est nul égal à faux » pour la variable créée dans l’élément Get. Si vous êtes un codeur, imaginez qu’il s’agit de votre chèque « null ».

Collections vides : Certaines actions ou composants d’écran invocables généreront une collection « vide » qui n’est pas considérée comme « nulle ». Un exemple classique de ceci est le composant « File Upload » prêt à l’emploi qui renverra une collection de texte vide si rien n’est téléchargé. Si vous rencontrez cela, le moyen le plus simple de prendre une décision ici est d’affecter la collection à un numéro à l’aide d’un élément Affectation et de prendre votre décision à partir de la valeur numérique.

Ne pas coder en dur les identifiants

Flow ne vous permet pas encore de référencer le nom du développeur d’éléments tels que le type d’enregistrement, les files d’attente ou les groupes publics dans certaines parties de l’interface utilisateur, mais cela ne signifie pas que vous devez coder en dur l’ID.

Utilisez plutôt les résultats d’un élément Get, d’une étiquette personnalisée ou de métadonnées personnalisées. Cela vous évitera des maux de tête lors du déploiement dans vos environnements, car les ID de type d’enregistrement et d’autres identifiants uniques peuvent différer d’un environnement à l’autre.

Par exemple, créez une étape de recherche Get Records sur l’objet RecordType. Ensuite, dans vos conditions, fournissez les champs DeveloperName et Object, et stockez l’ID d’enregistrement trouvé (ID de type d’enregistrement) pour une utilisation ultérieure dans votre flux.

Besoin de référencer une file d’attente ou un groupe public ? Faites un « Get » en utilisant le DeveloperName de la file d’attente sur l’objet Group au lieu de coder en dur l’ID.

Apprenez à vous familiariser avec la riche documentation fournie par Salesforce sur les objets de configuration tels que Grouper, Type d’enregistrement, et ContenuDocumentLink. Comprendre le modèle de données Salesforce fera de vous un administrateur et un concepteur de flux infiniment plus puissant.

Faites attention lors de la boucle

Il y a trois problèmes principaux lors du bouclage : les limites des éléments, les limites SOQL et l’utilisation de formules complexes.

1. Attention à la limite d’éléments exécutés — Chaque fois que Flow touche un élément, cela compte comme un exécution de l’élément. Depuis la version Spring ’21, il y a actuellement 2 000 exécutions d’éléments autorisées par entretien de flux. Considérez un scénario dans lequel vous bouclez plus de 1 500 contacts.

Dans votre boucle, vous avez votre élément de boucle (1), un élément de décision (2), une étape d’affectation pour définir certaines variables dans votre enregistrement en boucle (3) et une étape dans laquelle vous ajoutez cet enregistrement à une collection à mettre à jour, créer ou supprimer plus tard dans le flux (4). Chacun de ces quatre éléments dans la boucle comptera dans votre limite d’exécution. Cela signifie que votre boucle sur 1 500 enregistrements aura 6 000 éléments exécutés, ce qui dépassera de loin la limite d’itération.

Lorsque vous approcherez de cette limite, vous devrez probablement faire preuve de créativité en forçant un « arrêt » dans la transaction ou en rendant votre flux plus efficace en utilisant des actions invoquées. Gardez à l’esprit que la transaction se termine lorsqu’un élément Pause est atteint ou, dans les flux d’écran, lorsqu’un écran/une action locale est affiché.

2. Ne mettez pas de DML dans une boucle (Obtenir, mettre à jour, supprimer, créer) à moins que vous ne soyez sûr à 100 % que la portée ne déclenchera aucune limite de gouverneur. Habituellement, ce n’est le cas que dans les flux d’écran lorsque vous parcourez un petit sous-ensemble d’enregistrements. À la place, utilisez Apex invoqué si vous devez appliquer une logique compliquée sur une collection.

3. Soyez prudent avec les variables de formule complexes Par le Guide de décision d’automatisation déclenchée par enregistrement, « Le moteur de formule de Flow présente sporadiquement des performances médiocres lors de la résolution de formules extrêmement complexes. Ce problème est exacerbé dans les cas d’utilisation par lots, car les formules sont actuellement à la fois compilées et résolues en série pendant l’exécution. Nous évaluons activement les options de compilation de formules adaptées aux lots, mais la résolution des formules sera toujours en série. Nous n’avons pas encore identifié la cause première des mauvaises performances de résolution des formules.

Créer des chemins de panne

Avant de créer votre flux, réfléchissez à ce qui devrait se passer si une erreur se produit. Qui doit être notifié ? Doit-il générer un enregistrement de journal ?

L’une des erreurs les plus courantes commises par un concepteur de flux en devenir est de ne pas créer de chemins de défaillance. Un chemin d’erreur est conçu pour gérer lorsqu’un flux rencontre une erreur, et vous lui dites ensuite ce qu’il doit faire — considérez-le comme une gestion des exceptions. Les deux utilisations les plus courantes sont l’affichage d’un écran d’erreur pour les flux basés sur l’écran ou l’envoi d’une alerte par e-mail contenant le message d’erreur à un groupe de personnes.

J’aime généralement faire passer les erreurs aux sous-flux qui gèrent les erreurs pour moi ; de cette façon, si jamais j’ai besoin de modifier un aspect du chemin d’erreur, je n’ai besoin de le faire qu’à un seul endroit pour tous mes flux.

6. Faites attention au « contexte » du flux dans les flux d’écran

Faites toujours attention au contexte dans lequel votre flux s’exécute lorsque vous utilisez un flux d’écran. Si vous exécutez un flux d’écran sous User Context, ne créez pas d’élément Get sur un objet que l’utilisateur ne peut pas voir, comme les champs spécifiques à l’administrateur sur l’objet User ou les objets de configuration.

Testez en tant que base d’utilisateurs cible et utilisateurs ne faisant pas partie de votre public cible. Vous ne voulez pas que les utilisateurs aient une expérience difficile dans un flux qui ne leur était pas destiné. Utilisez des éléments tels que des autorisations spécifiques au flux ou des autorisations personnalisées attribuées via des ensembles d’autorisations pour contrôler l’accès au flux si vous avez besoin d’un contrôle granulaire au sein de vos flux. Besoin de contrôler l’accès à l’ensemble du flux ? Utiliser les autorisations de flux. Besoin de contrôler l’accès à des éléments spécifiques d’un même flux ? Utilisez une autorisation personnalisée attribuée via un ensemble d’autorisations.

Si vous avez vraiment besoin de récupérer des champs ou des enregistrements au niveau du système (comme des enregistrements de métadonnées personnalisées), utilisez des sous-flux avec des autorisations de contexte « Système » élevées pour effectuer des tâches clés auxquelles vous pouvez faire appel à travers les flux.

Pour les implémentations de niveau entreprise, envisagez d’utiliser une stratégie de journalisation complète dans laquelle les flux consignent les erreurs au même endroit que votre code Apex. Vous pouvez utiliser un outil comme Enregistreur de nébuleuse pour écrire dans un objet Log personnalisé lorsque votre flux échoue, ou simplement pour qu’un sous-flux à autorisation élevée crée des enregistrements de journal pour vous si vous n’avez besoin de rien d’extraordinaire.

7. Essayez de ne pas mélanger Apex, Process Builders, Workflow Rules et Record-Triggered flow

Chaque objet doit avoir une stratégie d’automatisation basée sur les besoins de l’entreprise et de l’équipe Salesforce qui la prend en charge. En général, vous devez choisir un outil d’automatisation par objet. L’un des nombreux scénarios inévitables des organisations plus anciennes consiste à mélanger des déclencheurs Apex avec des flux/processus lancés automatiquement ou, plus récemment, des générateurs de processus mélangés avec des flux déclenchés par enregistrement. Cela peut conduire à divers problèmes :

  1. Mauvaise performance
  2. Résultats inattendus dus à l’impossibilité de contrôler l’ordre des opérations dans la « pile »
  3. Augmentation de la dette technique avec les administrateurs / développeurs ne collaborant pas
  4. Dette de documentation

Une approche courante consiste à séparer l’activité DML et à la décharger sur Apex, et à laisser les outils déclaratifs gérer les activités non DML telles que les alertes par e-mail et les alertes dans l’application. Nous sommes encore dans la phase de « l’ouest sauvage sauvage » des flux déclenchés par un enregistrement, car les architectes et les administrateurs trouvent le meilleur moyen de les incorporer dans leurs systèmes.

J’ai vu des organisations plus aventureuses utiliser des gestionnaires de déclencheurs pour déclencher des flux lancés automatiquement (voir Mitch Spano cadre à titre d’exemple). C’est un moyen fantastique d’amener les administrateurs et les développeurs à collaborer.

Voici un excellent article sur les pièges du mixage de diverses automatisations par Mehdi Maujood.

Maintenir le montant des flux au minimum

Encore une fois, n’implémentez pas de flux After-Save si vous avez déjà de nombreux Apex ou Process Builders actifs sur un objet ! Créez une stratégie de migration ou envisagez d’attendre la prise en charge des sous-flux avant de déplacer vos principaux objets (comptes, requêtes, contacts) vers des flux déclenchés par enregistrement.

Maintenez la quantité de flux déclenchés par enregistrement par objet au minimum. Bien qu’il n’y ait pas vraiment de règle d’or, une bonne règle empirique consiste à séparer les flux par fonction commerciale ou par rôle afin qu’il y ait peu ou pas de risque de conflit dans l’ordre d’exécution. Le contrôle de l’ordre d’exécution en maintenant la quantité de flux au minimum garantit un résultat cohérent pour un événement dans le système.

En parlant de benchmarks et de performances, utilisez toujours les flux Before-Save chaque fois que vous mettez à jour le même enregistrement qui a déclenché l’automatisation. Selon le Guide de l’architecte pour l’automatisation déclenchée par enregistrement, les flux Before-Save sont SIGNIFICATIVEMENT plus rapides qu’After-Save et sont presque aussi performants qu’Apex.

Étant donné que les sous-flux ne sont pas encore pris en charge, je recommande généralement de ne pas déplacer vos objets principaux vers des flux déclenchés par enregistrement jusqu’à ce que nous soyons en mesure de créer des flux de « gestionnaire » plus propres qui utilisent des sous-flux pour ces objets.

8. Créez une dérivation dans vos flux pour les chargements de données et l’amorçage du bac à sable

Ce n’est pas une bonne pratique spécifique à Flow, mais c’est une bonne idée d’inclure un contournement dans vos déclencheurs et votre automatisation déclarative. Avec une telle stratégie de contournement, vous pouvez désactiver toutes les automatisations pour un objet (ou globalement) si jamais vous avez besoin d’importer des données en masse. Il s’agit d’un moyen courant d’éviter les limites du gouverneur lors de l’amorçage d’un nouveau bac à sable ou du chargement de grandes quantités de données dans votre organisation.

Il existe de nombreuses façons de le faire – soyez simplement cohérent dans vos automatisations et assurez-vous que vos contournements sont tous au même endroit (comme un type de métadonnées personnalisées ou une autorisation personnalisée).

9. Comprendre comment les flux programmés affectent les limites du gouverneur

La sélection de votre portée d’enregistrement au début de la configuration d’un flux planifié aura d’énormes ramifications de limite de gouverneur pour ledit flux. Lorsque nous disons « configuration de la portée », nous nous référons à cet écran où nous sélectionnons les conditions sObject et Filter :

, Le guide ultime des meilleures pratiques et normes de flux<span class="wtr-time-wrap after-title"><span class="wtr-time-number">24</span> minutes de lecture</span>

Lors de la spécification de la portée de l’enregistrement dans le début du flux (ci-dessus)

Un entretien de flux est créé pour chaque enregistrement récupéré par la requête du flux planifié.

Le nombre maximum d’entretiens de flux programmés par 24 heures est de 250 000, ou le nombre de licences utilisateur dans votre organisation multiplié par 200, selon la valeur la plus élevée.

Cela signifie que vous ne pouvez pas agir sur 250 000 enregistrements ou plus (ou quelle que soit la limite basée sur la licence utilisateur) par 24 heures en utilisant la méthode ci-dessus. Si vous avez besoin de travailler avec plus, nous vous recommandons de suivre la voie d’une action invocable et de ne pas spécifier votre portée ici. Vous devrez peut-être examiner Batch Apex et le traitement asynchrone – demandez de l’aide à un développeur dans ces scénarios.

De plus, le moteur Flow regroupe également les enregistrements par lots de 200 pour assouplir les limites du régulateur. Cela signifie que 200 enregistrements = 1 transaction mais 200 entretiens de flux. Ainsi, si vous avez 800 enregistrements identifiés dans votre périmètre initial, vous utiliserez 800 entretiens de flux et 4 transactions.

Gardez à l’esprit que bien que le flux soit gonflé, la limite d’itération du flux prendra toujours effet. Si un enregistrement défini dans votre étendue dépasse la limite d’itérations d’éléments de 2 000, vous obtiendrez des erreurs. Soyez extrêmement prudent lorsque vous utilisez Apex invoqué ici également, car il peut être difficile d’écrire des actions invocables correctement groupées dans Apex.

Lors de la spécification de la portée dans le flux (action invoquée, obtenir des enregistrements)

Les limites seront plus alignées sur ce à quoi vous êtes habitué avec un seul flux, ce qui signifie qu’un entretien sera créé pour le flux au lieu d’un par enregistrement. Si vous suivez cette voie, ne spécifiez pas de portée pour le même ensemble d’enregistrements (re: capture d’écran ci-dessus) ! Si vous le faites, le flux s’exécutera pour N² enregistrements, atteignant rapidement les limites.

Suivez cette voie lorsque vous avez besoin d’avoir plus de contrôle sur les limites et que vous souhaitez appeler Apex qui peut impliquer un traitement SOQL ou complexe.

Dans ce scénario, si vous disposez d’un « Get Records » initial qui renvoie 800 enregistrements, Flow n’essaiera pas de regrouper ces enregistrements. Gardez à l’esprit que l’utilisateur en cours d’exécution est toujours un utilisateur de processus automatisé, ce qui entraîne certaines bizarreries telles que l’impossibilité d’afficher tous les groupes de collaboration (groupes Chatter) ou les bibliothèques.

Double trempage : Encore une fois, NE sélectionnez PAS une étendue d’enregistrement et effectuez une étape Obtenir des enregistrements pour le même ensemble d’enregistrements ; vous multiplierez effectivement la quantité de travail que votre flux doit faire par N² et vous atteindrez rapidement les limites.

Quel chemin choisir ?

Il n’y a pas de bonne ou de mauvaise réponse quant à la voie à choisir. Il existe moins de moyens contrôlés par l’utilisateur de contrôler les limites associées au premier itinéraire – vous ne pouvez pas spécifier la taille de votre lot ou le nombre total d’enregistrements dans la portée. Donc, si vous avez besoin d’un contrôle plus strict autour des limites, il peut être préférable de créer un invocable et de spécifier votre portée de cette façon. Ou, ne le faites pas dans un flux planifié : utilisez une tâche planifiée avec Apex.

Pour en savoir plus sur les considérations relatives aux flux planifiés, consultez la documentation officielle : Considérations relatives aux flux déclenchés par la planification.

10. Consultez la liste de contrôle !

Vous êtes prêt à créer de superbes flux ! Voici une liste de contrôle pratique qui s’applique à chaque flux :

1. Éléments et descriptions documentés : Assurez-vous que votre flux a une description solide, une convention de nommage décente pour les variables et des descriptions pour les éléments de flux qui pourraient ne pas avoir de sens si vous les revisitez dans 6 mois.

2. Chèques nuls/vides : N’oubliez pas de vérifier les résultats Null ou Empty dans les éléments de décision avant d’agir sur un ensemble d’enregistrements. Ne présumez pas d’un chemin heureux – pensez à tous les scénarios possibles !

3. ID codés en dur : Ne codez pas en dur les identifiants pour des éléments tels que les identifiants de propriétaire, les identifiants de file d’attente, les groupes ou les identifiants de type d’enregistrement. Faites un « Get » pour l’objet respectif en utilisant le DeveloperName.

4. Logique codée en dur : Ne codez pas en dur la logique de référence dans une décision qui pourrait changer fréquemment, comme les ID de file d’attente, les ID de propriétaire ou les nombres (comme un pourcentage de remise). Utilisez des étiquettes personnalisées et des métadonnées personnalisées !

5. Boucles imbriquées et « hacks » excessifs : Tirez-vous les performances de Flow à sa limite alors que le code pourrait être mieux adapté ? Utilisez des invocables Apex génériques que vos développeurs créent, ou utilisez des composants du Composant d’automatisation bibliothèque ou Non officielSF plutôt.

6. Boucle sur de gros volumes de données : Ne bouclez pas sur de grandes collections d’enregistrements qui pourraient déclencher la limite de l’élément Flow (actuellement 2 000).

7. Vérifiez la sécurité de l’enregistrement et du champ et le contexte du flux : Ne présumez pas que votre utilisateur peut voir et faire tout ce que vous avez conçu si vous créez un flux d’écran. Testez vos flux en tant que publics visés et non visés.

8. DML en boucle : Ne faites pas de DML à l’intérieur d’une boucle dans un flux lancé automatiquement ou un flux déclenché par un enregistrement. Les flux d’écran sont corrects si vous êtes sûr à 100% que la portée ne déclenchera pas les limites du gouverneur.

9. Erreurs de flux : Que voulez-vous qu’il se passe lorsque le flux rencontre une erreur ? Qui doit être notifié ? Utilisez ces chemins de défaut !

10. Contournement de l’automatisation : Votre flux lancé automatiquement ou déclenché par un enregistrement dispose-t-il d’un contournement basé sur les paramètres personnalisés/les métadonnées personnalisées ?

Conclusion

Si vous êtes arrivé jusqu’ici, félicitations ! Vous êtes sur la bonne voie pour devenir un constructeur professionnel de Flow, et vous n’êtes pas seul ! Rejoins Communauté des pionniers de l’automatisation de Salesforce et connectez-vous avec d’autres administrateurs Salesforce du monde entier. Cette communauté est un endroit idéal pour en savoir plus sur les flux que d’autres administrateurs créent, écouter les dernières mises à jour des Product Owners et poser des questions sur Flow. J’espère que vous avez trouvé ce guide utile, et j’ai hâte de voir tous les flux que vous créez !

Assurez-vous de vérifier mon dernier article sur Flow sur le blog de l’Architecte également.

Ressources



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer