Flows vs Code

Durant les projets d’intégration Salesforce, le sujet du choix d’outil est souvent l’un des plus complexes.
Pour un besoin donné, que faut-il choisir ? Flows, Code, AppExchange ?

Cela fait maintenant des années que Salesforce améliore ses outils low-code avec notamment un grand investissement sur les flows.
Si on écoute à la lettre les recommandations Salesforce, il faut toujours choisir en priorité les flows.
Mais dans les faits, est-ce toujours aussi simple ?

Dans cet article, je vais m’aider de mes 10 années d’expérience à developper des flows et avec du code pour répondre à la question suivante :
Quand est-ce que qu’il vaut mieux utiliser du code plutôt que des flows ?

Pour répondre à cette question, je vais découper cet article en fonction des technologies opposées les unes aux autres :

• Triggered flows versus Triggers
• Screen flows versus Lightning Web Components

Triggered flows versus Triggers

Je commence donc par les deux technologies dont j’ai eu le plus besoin tout au long de ma carrière.

Depuis que j’ai commencé à travailler sur Salesforce, les triggered flows ont énormément changés. Salesforce a amélioré cette technologie au fil des années. Et il est vrai qu’aujourd’hui, pour un besoin de complexité simple ou moyenne, il n’existe je pense plus aucune limitation technique concernant les flows. Je détaillerai plus en détail en suivant ce que je considère être de complexité élevée.

En revanche, mon point de vue est que même si un flow est capable de réaliser la même chose que du code, est-il vraiment toujours plus avantageux de créer un flow plutôt qu’un trigger? Pour répondre à cette question, je vais commencer par parler d’un sujet qui me tient à coeur.

Maintenabilité

La maintenabilité est l’argument principal de Salesforce pour justifier l’utilisation des flows.
Effectivement, il est beaucoup plus facile pour un public non averti ou un administrateur Salesforce de s’initier au développement de flows. Il y a donc plus de personnes capables d’administrer un flow que d’écrire du code.

En revanche, est-ce que la maintenabilité d’un développement doit se baser entièrement sur les personnes en capacité de le corriger ou améliorer ? Je ne pense pas.

Pour justifier mon point de vue, je vais m’appuyer sur l’image suivante.

Ah mince excusez-moi, même avec un flow d’une simplicité extrême, il est impossible de voir l’ensemble du flow dès l’ouverture de celui-ci. J’ai oublié de dézoomer. On reprend.

L’image ci-dessus représente un flow et un trigger juxtaposés. Ces deux composants qui rentrent dans la catégorie « simple » mentionnée précédemment ont exactement le même comportement : lorsque la valeur d’un champ personnalisé Discount__c de l’Account est mise à jour, elle doit être transmise à tous les order items liés aux orders au statut « Draft » de l’account en question.

En tant que développeurs, nous pouvons faire les remarques suivantes par rapport au flow et au trigger :

•  Comme nous l’avons vu par le biais des captures d’écran, même un flow simple ne peut pas être visualiser entièrement sans l’intervention d’un clic
• Nous n’avons aucune visibilité sur les critères d’entrée du flow sans avoir cliqué sur l’élément de démarrage du flow
• Même si tout est correctement nommé et décrit dans un flow (ce qui n’arrive pas toujours), il est impossible de voir ce qui se passe réellement sans avoir cliqué sur chaque composant du flow un par un
• Le trigger lui est capable de requêter des enregistrements directement en se basant sur le parent. Dans le flow, nous sommes obligés de passer par deux éléments de requête et une boucle.
• En ouvrant le trigger, ou le trigger handler si vous appliquez à la lettre les bonnes pratiques (ce qui n’est pas le sujet de cet article), vous avez une visibilité totale sur votre écran de ce qui est automatisé

1. Souplesse : si nous écrivons du code, il doit pouvoir être maintenu dans le futur
2. Complexité : le code peut s’avérer plus facile à maintenir pour les personnes compétentes en la matière

Concernant la complexité, nous avons déjà vu que même pour des flows simples, le code peut s’avérer plus facile à maintenir. Qu’en est-il des autres types de flows?

Complexité

Selon moi, la complexité d’une automatisation est engendrée par de multiples facteurs :

• le nombre d’opérations : nous avons déjà vu un flow et un trigger très simples comportant un très faible nombre d’opérations mais j’imagine que vous avez déjà ouvert des flows qui vous ont fait peur. C’était probablement dû au très grand nombre d’opérations qu’il contenait (requêtes, mises à jour de la base de données, décisions, …).
• la volumétrie de données traitée : ce facteur est probablement le plus compliqué à juger car il est important d’anticiper. Nous détaillerons plus en profondeur dans la suite de l’article.
• la synchronisation avec des systèmes externes : même si les flows ont bien évolué dans ce sens, les appels APIs semblent rester un sujet trop critique pour être traité hors du code. Que ce soit pour la gestion des erreurs, le système de logs, le débuggage et ou les tests unitaires.
• l’implication de traitements asynchrones : même si sur le papier les flows sont capables de traiter de l’asynchrone, leur capacité est très limitée. Surtout si l’automatisation nécessite de multiples traitements couplés par exemple à des appels APIs. Nous pouvons cités les mêmes exemples de limitations que pour la synchronisation avec les systèmes externes.

Focus sur la volumétrie de données

Si vous discutez avec un intégrateur Salesforce expérimenté et que vous lui demandez ce qu’il déteste le plus, il y a de grandes chances qu’il cite les governor limits.
Je serais le premier à le répondre même si je suis convaincu qu’elles sont le gardien d’une bonne qualité d’implémentation Salesforce.

Pour moi, c’est le plus gros soucis des flows. Ils sont supposés être optimisés pour limiter l’utilisation des appels DML (insert, update, …) ou des requêtes en bases de données mais nous n’avons aucun contrôle sur ce qu’il se passe réellement.

Tout au long de ma carrière, je ne compte plus le nombre d’interventions que j’ai dû réalisées pour migrer des flows vers du code.
Lors des intégrations, les flows avaient été privilégiés mais la volumétrie de données avait augmenté au fil du temps et les flows n’étaient plus capables de gérer les traitements. Ainsi, pour la plupart, les limites suivantes étaient atteintes :

• nombre maximum de requêtes exécutées dans un même traitement
• nombre maximum d’appels DML exécutés dans un même traitement

Toutes ces expériences de migration me confortent dans l’idée suivante : ce n’est pas parce qu’un flow marche aujourd’hui qu’il marchera dans les prochains mois. Et je pense que c’est ce qu’il faut garder en tête en permanence avant de choisir d’intégrer des flows.

Alors dans ce cas-là, comment fait-on?

Avant de choisir entre créer un flow ou du code, voici les étapes de vérification que j’effectue :

1. Quelle est la volumétrie de données actuelle qui va entrer dans l’automatisation ? Combien d’enregistrements répondant aux critères vont entrer dans l’exécution au même moment ?
2. Quel est le ratio d’enregistrements répondant aux critères par rapport au nombre d’enregistrements total ?
3. Quelle est la tendance de croissance du nombre d’enregistrements sur les derniers mois ? Pour cela je m’appuie sur la date de création des enregistrements groupée par mois, ce qui me permet de calculer une tendance.
4. Le ratio calculé dans le point 2 cumulé à la croissance calculée dans le point 3 permettent de répondre à la question suivante : dans quelques mois, combien d’enregistrement vont être potentiellement traités en même temps dans l’exécution de l’automatisation ?
5. Enfin, la question la plus importante : est-ce que l’automatisation va déclencher l’exécution d’autres automatisations déjà intégrées ? Est-ce que l’automatisation va par exemple mettre à jour des comptes et un flow déjà existant sur les comptes va être exécuté ?

Pour rentrer dans le concret, nous allons imaginer un exemple :
Lorsqu’une ligne de commande est insérée dans la plateforme Salesforce, je souhaite retrouver le compte lié à la commande pour mettre à jour ses statistiques d’achat (montant total de ses achats par famille de produit) et aussi mettre à jour les statistiques d’achat du produit concerné.

Reprenons la liste des questions que nous devons nous poser :

1. Les lignes de commandes sont intégrées à Salesforce par le biais d’un système externe. Aujourd’hui, le système externe envoie environ 100 lignes de commande en même temps.
2. Je n’ai pas de critère d’entrée, l’automatisation doit s’exécuter pour chaque ligne de commande insérée. Nous devons donc traiter les 100 lignes de commandes.
3. Analysons maintenant la croissance de mon entreprise en termes de commandes et lignes de commandes. Voici la tendance de croissance sur les 8 derniers mois :
   
   La croissance moyenne est donc d’environ 9 lignes de commandes par mois.
4. Dans 11 mois, nous devrions donc atteindre les 200 lignes de commandes envoyées à Salesforce dans la même transaction.
5. Il existe déjà deux autres automatisations sous la forme de deux flows, l’un lié à la mise à jour du compte et l’autre la mise à jour du produit. Le premier analyse les statistiques d’achat du compte pour mettre à jour un scoring personnalisé déjà présent sur le compte. Le deuxième sur le produit permet de désactiver le produit lorsqu’il n’y a plus de stock.

Etant donné que dans le prochains mois 200 lignes de commandes seront insérées dans la même exécution, imaginons le pire scénario :

• Ces 200 lignes de commandes concernent 200 commandes différentes mais aussi 200 comptes différents
• Ces 200 lignes de commandes concernent 200 produits différents

Nous aurons donc le résultat suivant :