J'aurais aimé commencer à utiliser les workflows plus tôt
Parfois, dans la vie, on se surprend à résister au changement, même quand on perd à ne pas s'adapter. Les workflows étaient l'une de ces choses qui, pour moi, signifiaient simplement « ... si ce n'est pas cassé, ne le répare pas ». C'est assez étrange de se retrouver opposé à quelque chose simplement parce qu'on aimait la façon dont c'était avant – j'aimais contrôler tous les détails à l'aide des microflows et je ne voulais pas abandonner le contrôle sur les petits détails de mes projets. Voyons pourquoi je me suis trompé et pourquoi ce n'est pas une question de workflows contre microflows, mais de workflows ET de microflows.
Que sont les flux de travail
Les workflows permettent de définir des processus à un niveau d'abstraction plus élevé que les microflows. Ils permettent de gérer et d'étendre les processus métier courants qui sont exécutés régulièrement au sein d'une organisation. Bien qu'ils ressemblent visuellement aux microflows dans Studio Pro, ils sont davantage axés sur les tâches exécutées par l'utilisateur ou le système, généralement sur une période allant de quelques heures à, dans de rares cas, parfois même des années. Comme ils sont davantage axés sur les tâches, vous bénéficiez d'un contrôle précis sur chaque tâche et sur l'état général du workflow.
Ils y parviennent grâce à une variété d’outils dans la boîte à outils qui vous permettent de sauter des étapes et d’attendre la confirmation que d’autres ont terminé leur exécution avant de passer à la suivante, pour n’en citer que quelques-uns.

Et pour tout ce qui sort de l'ordinaire, vous pouvez toujours étendre la boîte à outils en utilisant vos propres microflux et même déclencher de nouveaux flux de travail pour vous adapter rapidement aux scénarios changeants.

Tout cela n’est-il pas possible avec les microflux ?
Oui. C'est ce qui m'a longtemps dérouté. Même si tout est réalisable avec les microflux, parfois les workflows améliorent simplement le processus pour toutes les personnes impliquées.
Bien qu'il soit possible de créer des processus sans utiliser de workflows, la création manuelle de tout cela nécessite une planification minutieuse et des efforts supplémentaires pour garantir une gestion efficace des processus. En utilisant uniquement des microflux pour gérer l'état, envoyer des notifications, gérer la sécurité, la navigation... vous pouvez obtenir des résultats similaires, mais vous créerez une complexité supplémentaire et avec moins de support prêt à l'emploi qu'en utilisant des workflows.
Cette complexité peut créer un fouillis difficile à comprendre pour les autres personnes qui travaillent sur le projet avec vous et qui devront peut-être maintenir l'application à l'avenir. Comme les workflows présentent clairement le processus en séquence, ils sont en quelque sorte auto-documentés et constituent donc un moyen simple de documenter clairement un processus qui s'étend sur de nombreuses étapes. Si les workflows peuvent faire gagner du temps lors du développement, l'un des plus grands avantages est pour l'équipe et l'organisation, grâce au temps gagné dans la maintenance des applications créées à l'aide de workflows.
Quand les workflows sont une bonne idée
Il existe d’autres considérations quant au moment où un flux de travail est nécessaire ou utile.
Les workflows sont particulièrement adaptés pour définir et décrire des processus importants, qui peuvent se dérouler sur une longue période et comporter généralement de nombreuses étapes. L'obtention d'un devis pour une assurance ou un autre type de contrat en est un bon exemple. Après le premier contact, la collecte d'informations et l'établissement d'un devis, le client doit ensuite accepter ou refuser l'offre avant que la demande ne soit finalisée. Il s'agit d'un processus clairement défini qui implique à la fois des tâches humaines et des tâches système.
Il s'agit également d'un processus qui ne changera pas fréquemment. Au fil du temps, l'entreprise peut proposer des options différentes ou de nouveaux produits, mais le processus d'obtention d'un devis et d'acceptation de celui-ci ne changera pas radicalement.

Vous devez également envisager d'utiliser des workflows lorsqu'il existe un mélange de tâches système et utilisateur. Dans l'exemple d'une police d'assurance, le client devra accepter certaines clauses de non-responsabilité et certains documents de conformité, qui sont normalement envoyés par courrier électronique. Le déclenchement des courriers électroniques à partir du système qui attendent une action de l'utilisateur ou du client est simplifié grâce aux fonctions de division et d'attente parallèles intégrées aux workflows.
Il présente également l’avantage supplémentaire d’auto-documenter le processus, créant ainsi un arbre de décision clair qui peut être facilement compris par quiconque ouvre le projet.
Quand ne pas utiliser les workflows
Le non-respect des critères ci-dessus ne constitue pas une disqualification immédiate pour l'utilisation d'un workflow, même si cela devrait déclencher quelques signaux d'alarme. Cependant, il existe plusieurs indicateurs clairs indiquant que vous ne devez pas utiliser de workflows :
- Lorsque le processus est susceptible de changer à l'avenir. La nature imprévisible du travail avec des résultats inattendus ne s'intègre pas parfaitement dans le cadre du flux de travail.
- Si le processus est imprévisible et davantage axé sur l'obtention du résultat souhaité, la rigidité des flux de travail ne permettra pas de tenir compte des nombreux résultats possibles. Il est préférable d'avoir un objectif ou une destination claire.
- Les processus qui nécessitent un degré élevé de liberté pour que les utilisateurs puissent décider du meilleur chemin à suivre pourraient ne pas s’adapter aux contraintes strictes des flux de travail.
En résumé, il est préférable d’utiliser des workflows pour les processus prévisibles qui se répètent souvent et qui ne s’écarteront pas du processus standard décrit dans le workflow.
Ils ne sont pas exclusifs
La principale raison pour laquelle j'ai changé d'avis sur les workflows est que j'ai réalisé qu'ils ne sont pas l'un ou l'autre. Vous pouvez et devez avoir les deux dans une application. Vous pouvez penser que votre application est spécialisée et ne rentrera pas dans une case, mais chaque application a des processus qui sont courants et peuvent facilement être définis dans un workflow, et pour les éléments plus complexes, les micro-flux sont toujours une option.
En prenant l’exemple d’un devis d’assurance, toute personne ayant une assurance sait à quoi ressemble le processus : l’agent passe du temps à recueillir vos informations, à poser des questions sur votre mode de vie et vos risques, à soumettre vos informations pour souscription, puis à accepter ou à rejeter le devis proposé avant d’envoyer des e-mails pour confirmer et documenter l’ensemble de l’opération. Il s’agit d’étapes claires qui ne changeront pas, avec un mélange clair de tâches utilisateur et système. Le processus prend normalement quelques minutes à une heure et peut impliquer que l’utilisateur quitte l’application pendant un moment pour effectuer une tâche en dehors de votre système (ouvrir l’e-mail pour confirmer votre compte).
Vous pourriez créer une solution entièrement personnalisée pour cela, mais cela générerait rapidement des centaines de documents dans votre projet, qui peuvent facilement être remplacés par un flux de travail unique avec quelques microflux soigneusement élaborés. Vous n'êtes pas obligé de créer toute votre application en utilisant uniquement des flux de travail, mais trouver des processus clairs qui peuvent être remplacés par eux facilitera la maintenance du projet pour vous-même et pour les autres. Vous gagnerez du temps pendant et après la fin du développement. Les microflux et les flux de travail ont tous deux des utilisations et des avantages dans ce cas et ne pas les inclure tous les deux serait une occasion manquée de créer une meilleure application.
Pourquoi j'étais réticent au changement
Je pense que la raison pour laquelle j'ai évité les workflows était une mauvaise compréhension de ce que sont les workflows. Ils ne remplacent pas directement les microflows, mais constituent un moyen plus efficace d'organiser des processus complexes à grande échelle. Ils ne sont pas destinés à remplacer les microflows, mais plutôt à fournir un cadre et une structure sur la manière dont les microflows sont utilisés pour soutenir les processus métier, ce qui rend le projet plus facile à maintenir et à modifier à l'avenir. Bien qu'ils soient censés améliorer l'efficacité, les gains d'efficacité les plus importants se produisent après le développement initial du projet et impliquent principalement la rationalisation du processus et le rendre plus lisible pour les développeurs qui viendront après vous.
En repensant à certaines des applications que j'ai créées, je me suis rendu compte que j'aurais pu gagner beaucoup de temps, à moi et à d'autres, si j'avais choisi d'utiliser des workflows. Parfois, il est plus judicieux de passer du temps à comprendre quelque chose de nouveau plutôt que de continuer comme d'habitude.