Concevoir un processus

Objectif

Dessiner un processus : les couloirs qu’il traverse, les étapes de chacun et les connexions qui les relient.

Ouvrir le concepteur

Depuis Processus, sélectionnez un processus et choisissez Concevoir — ou cliquez sur la ligne. Le canevas s’ouvre dans l’application, avec le fil d’Ariane et la barre de titre toujours au-dessus.

Un processus que vous n’avez jamais dessiné s’ouvre sur un schéma de départ plutôt que sur un canevas vide : un couloir, un début et une fin. C’est la forme qu’a tout processus, c’est donc la forme dont vous partez.

Les quatre zones

• La palette, sur le bord gauche — ce que vous pouvez ajouter : un couloir et les types de nœud.
• Le plan, juste à côté — le processus sous forme d’arborescence : la racine, ses couloirs et les nœuds de chacun. Sélectionner dans le plan sélectionne sur le canevas, et inversement. Faites glisser son bord droit pour l’élargir.
• Le canevas, au centre — le schéma lui-même.
• Le panneau des propriétés, à droite — tout ce qui concerne l’élément sélectionné.

Couloirs : qui fait le travail

Ajoutez un couloir depuis la palette, ou faites-en glisser un sur le canevas. Nommez-le d’après le rôle, pas d’après la personne — « Responsable », pas un nom — car un processus survit à quiconque occupe le poste ce mois-ci.

• Renommez un couloir en double-cliquant sur son en-tête.
• Redimensionnez-le en faisant glisser la limite située en dessous. Les couloirs inférieurs se décalent vers le bas avec lui, leurs nœuds aussi.
• Un nœud appartient au couloir dans lequel il se trouve. Faites-le glisser dans un autre couloir et il change de mains.

Définissez le Rôle du couloir, ou ses étapes ne vont à personne

Nommer un couloir « Responsable » indique à un lecteur qui fait le travail. Cela ne l’indique pas au moteur. Sélectionnez le couloir et choisissez son Rôle dans le panneau des propriétés — une recherche parmi les rôles de sécurité de cet environnement, avec une zone de recherche : commencez à taper et la liste se restreint, par le nom du rôle ou par son nom logique.

C’était autrefois une zone où l’on saisissait le nom, si bien qu’une faute de frappe produisait un couloir dont le travail allait à un rôle inexistant — sans que rien ne le signale avant qu’une exécution ne s’arrête. Laissez-le vide et chaque étape décide pour elle-même.

Chaque tâche utilisateur de ce couloir va alors à quiconque détient ce rôle — c’est toute la raison d’être d’un couloir, et cela se règle une fois pour le couloir plutôt que sur chaque étape. Une étape dotée de sa propre expression Attribué à prend le pas sur lui.

attention

Un couloir sans Rôle avec des étapes sans Attribué à, c’est un processus qui s’exécute puis s’arrête avec « … n’a pu être attribuée à personne ». La tâche est tout de même créée, pour qu’un administrateur puisse la voir — mais elle ne figure dans la liste de personne.

Deux autres conditions doivent être réunies pour qu’un rôle atteigne une personne : le rôle doit exister (Rôles, dans le Centre de contrôle d’administration) et quelqu’un doit le détenir dans une unité (Rôles de processus, dans l’application Organisation). Voir Configurer votre organisation.

Nœuds : les étapes

Type	Ce qu’il signifie
Début	Là où le processus commence. Dessinez-en exactement un.
Fin	Là où il se termine. Il peut y en avoir plusieurs — approuvé et rejeté sont deux fins.
Tâche	Une étape. Celle que vous utiliserez le plus.
Branchement	Une décision : une entrée, plusieurs sorties.
Division	Se sépare en chemins qui s’exécutent tous.
Jonction	Attend que ces chemins se rejoignent.
Minuteur	Attend une durée, ou jusqu’à un moment donné. Personne n’a rien à faire.

Une tâche a aussi un type de tâche, choisi dans le panneau des propriétés — utilisateur, service, script, manuelle, envoi, réception, règle métier. Il dessine un petit badge sur le nœud, et c’est ainsi qu’un lecteur distingue d’un coup d’œil « quelqu’un remplit ceci » de « la plateforme le fait toute seule ».

Quelles étapes attendent

Seule une tâche Utilisateur fait attendre l’exécution après une personne. Tout autre type de tâche lance son À l’entrée et son À la sortie puis continue aussitôt ; son type est là pour qui lit le dessin.

Quand une exécution a plusieurs chemins

Après une Bifurcation, une exécution suit plusieurs chemins à la fois. Deux choix décident de ce qui se passe quand ils se terminent.

• Sur une Jonction, Continue quand : Tous les chemins sont arrivés (par défaut), Le premier chemin arrive ou Un certain nombre de chemins sont arrivés, avec Combien de chemins à côté. On compte les chemins lancés par sa Bifurcation, pas les connexions dessinées vers elle. Un chemin encore en cours quand la Jonction continue est arrêté, et sa tâche ouverte est retirée.
• Sur une Fin, Quand un chemin l’atteint : Terminer ce chemin (par défaut : l’exécution se termine quand aucun autre chemin n’est en cours) ou Terminer toute l’exécution, qui arrête tous les autres chemins. La seconde est la fin pour « refusé, on arrête tout ».

Le Titre et le Nom d’une étape

Chaque étape a les deux, et ils n’ont pas le même rôle — le même couple que le nom d’affichage et le nom logique d’une table.

• Le Titre est ce qu’affiche la boîte sur le canevas. Rédigez-le pour un lecteur, dans la langue de votre choix, et reformulez-le quand vous voulez.
• Le Nom est ce par quoi le code, l’historique d’exécution et un autre processus désignent l’étape. Il se compose de lettres minuscules, de chiffres et de traits de soulignement, et il est obligatoire.

Normalement, vous ne saisissez pas le nom. Il se remplit à partir du titre pendant que vous tapez — « Approve Leave » devient approveleave — et il cesse de le suivre dès que vous le modifiez vous-même, si bien qu’un nom que vous avez choisi n’est jamais écrasé. Videz la zone pour retrouver la suggestion.

Deux étapes ne peuvent pas partager un nom. Si un titre en dérive un déjà pris, la nouvelle venue reçoit _2 ; l’étape qui l’avait le conserve, car la renommer changerait ce que désigne chaque script qui y fait déjà référence.

astuce

Un titre en persan ou en arabe ne produit aucun nom : l’étape est alors nommée d’après son type — task, task_2. Renommez-la en quelque chose que vous reconnaîtrez dans l’historique d’une exécution.

Processus dessinés avant que les noms soient obligatoires

Un nom était autrefois facultatif : un processus dessiné plus tôt peut donc avoir des étapes sans nom — ou avec un nom dans l’ancien style libre. Ces documents ne sont plus acceptés.

Ouvrez chacun d’eux dans le concepteur et enregistrez-le. Les noms se remplissent à partir des titres à l’ouverture, et l’enregistrement suffit à tout corriger. Rien ne les convertit à votre place, et un processus que vous n’avez pas rouvert refusera d’être enregistré la prochaine fois que vous le modifierez.

Connexions

Choisissez Relier dans la palette, puis faites glisser d’un nœud à un autre. Les connexions sont tracées automatiquement — vous ne dessinez pas les angles.

• Donnez une étiquette à une connexion là où elle en a besoin. Sur les connexions sortantes d’un branchement, c’est ce qu’un lecteur prend pour la décision : Approuvé, Au-dessus du plafond, Rejeté.
• Le Style de connecteur — courbe ou à angles droits — se trouve sur la racine du processus et s’applique à tout le schéma, car un schéma qui mélange les deux se lit comme une erreur plutôt que comme un choix.

Variables : ce que le processus transporte

Sélectionnez la racine du processus dans le plan et ajoutez des Variables — les valeurs que ce processus transporte d’une étape à la suivante. Chacune a un nom et un type (texte, nombre, oui/non, date).

Le nom est ce qu’écrit un script : getVariable("total"). Renommer une variable ne réécrit pas les scripts qui la nomment : considérez donc le nom comme la chose même que vous nommez, et non comme une étiquette que vous pouvez changer librement. Une variable pas encore nommée n’est tout simplement proposée nulle part.

Formulaires de décision : ce qu’une personne remplit pour terminer une étape

Un formulaire de décision est le formulaire court que quelqu’un remplit pour terminer une tâche utilisateur, avec ses issues — les boutons qui la terminent. Ce n’est pas un formulaire piloté par modèle posé sur une table : il appartient au processus, voyage à l’intérieur du document du processus et ne demande que ce dont la décision a besoin.

Sélectionnez la racine du processus dans le plan — c’est là que s’ouvre le concepteur — et vous obtenez Formulaires de décision sous Variables, car un formulaire de décision appartient au processus plutôt qu’à une étape en particulier : plusieurs étapes peuvent afficher le même.

Chaque formulaire de décision comporte :

• Un nom de formulaire de décision, par lequel une tâche le désigne, et un en-tête, que voit la personne qui le lit.
• Des Champs — un nom de champ, un libellé et un type de données. Ce sont les types de champ propres de la plateforme : un formulaire de décision bénéficie donc des mêmes sélecteurs de date, calendriers et listes de choix qu’un formulaire d’enregistrement.
• Des Issues — une ligne par bouton. Le texte du bouton est ce qui y figure, le style est son apparence (ordinaire, principal, destructif), et Exige un commentaire fait insister ce seul bouton sur une réponse dans le premier champ multiligne du formulaire de décision. Activez-le sur un rejet et laissez-le désactivé sur une approbation : c’est pour cette différence que ce réglage existe.

Sélectionnez ensuite une tâche utilisateur et choisissez son Formulaire de décision dans la liste.

Une tâche sans formulaire de décision se termine quand même, mais la personne n’a aucun moyen de dire quoi que ce soit à son sujet. Un processus dont les étapes humaines ne demandent rien est généralement un processus dont la conception n’est pas terminée.

Ce qu’ils consultent pendant qu’ils décident

Sous le formulaire de décision, Ce qu’ils consultent choisit ce qui remplit la zone principale pendant que la personne décide : rien, le formulaire d’un enregistrement, une liste, un rapport ou un écran. Choisissez-en un et le reste de la section apparaît.

Champ	À quoi il sert
Application	L’application dans laquelle il s’ouvre. Laissez vide et il s’ouvre dans une application qui contient ce dont parle l’étape : celle où se trouve la personne, si elle le contient, sinon une application qui participe aux processus métier. C’est ce qui permet à un processus de fonctionner après avoir été importé ailleurs.
Table / Rapport / Écran	Ce sur quoi porte l’étape. Lequel des trois vous obtenez dépend de ce que vous avez choisi au-dessus.
Quel formulaire / Quelle vue	Un formulaire ou une vue nommés au lieu de ceux par défaut de la table. Vide, c’est la valeur par défaut.
Ouverture	En lecture seule ou en modification. La lecture seule est la réponse habituelle — quelqu’un lit pour décider — et la modification s’exécute avec les autorisations propres de l’enregistrement : une tâche n’accorde aucun accès par elle-même.

Chacun de ces champs est une liste déroulante de ce que cet environnement contient réellement. C’étaient des zones où l’on saisissait un nom logique, et un nom saisi à la main ne peut que mal s’orthographier — ce qui se traduit par « l’étape n’ouvre rien », des semaines plus tard, devant la personne pour qui le processus a été construit.

Sur quel enregistrement elle s’ouvre ne figure pas dans cette liste : c’est une expression, elle se trouve donc sous Code avec les autres. Généralement getRecordRef("request") — l’enregistrement sur lequel porte cette exécution.

Paramètres : ce que l’étape reçoit en plus

L’enregistrement répond à lequel, et sur un formulaire c’est généralement toute la question. Ce n’est pas toute la question ailleurs : un rapport veut la période qu’il couvre, un écran veut le montant à approuver et qui l’a demandé. Ces valeurs se trouvent dans cette exécution plutôt que dans l’artefact.

Sélectionnez Ajouter un paramètre, donnez-lui le nom qu’attend le rapport ou l’écran, et sa valeur apparaît comme une ligne sous Code — car une valeur est une expression portant sur les variables du processus et l’état de cette exécution : getVariable("month"), instanceStartedBy().

Les noms sont ce qui permet à l’artefact de trouver une valeur : deux paramètres ne peuvent donc pas partager le même, et un paramètre sans nom est abandonné à l’enregistrement du processus.

Issues : quelle décision emprunte une connexion

Une tâche utilisateur se termine quand quelqu’un appuie sur l’une des issues de son formulaire de décision, et chaque issue envoie le processus dans une direction différente. Sélectionnez une connexion qui part d’une tâche utilisateur et renseignez Emprunté quand — une liste déroulante des issues du formulaire de décision de cette tâche.

C’est ce qui fait d’Approuver ou rejeter une seule étape, plutôt qu’une tâche suivie d’un branchement qui redemande ce que la personne a déjà décidé.

• Ce réglage n’est proposé que là où la tâche affiche un formulaire de décision doté d’issues. Ailleurs, il n’y a rien à choisir.
• Un formulaire de décision avec une issue n’a besoin de rien de tout cela : un bouton, une sortie.
• Avec plusieurs, chacune demande sa propre connexion. Le panneau Problèmes le signale — il relève une issue qu’aucune connexion n’emprunte, deux connexions revendiquant la même, et une connexion nommant une issue que le formulaire de décision ne propose plus, ce qui arrive quand vous modifiez un formulaire de décision qu’une autre tâche affiche aussi.

Appeler un autre processus

Réglez le Type d’une tâche sur Appeler un processus et choisissez le Processus à exécuter. L’idée est que cette étape attende la fin de ce processus, puis continue — mais le moteur ne l’exécute pas encore. Le choix est conservé et le panneau des problèmes vérifie qu’un processus est choisi ; à l’exécution, l’étape lance son À l’entrée et son À la sortie puis continue aussitôt sans démarrer l’autre processus, comme toute étape qui n’est pas une tâche utilisateur.

Utilisez-le quand plusieurs processus ont besoin du même travail — une approbation, une vérification de solvabilité. Un processus appelé trois fois reste une seule chose à modifier ; trois copies de celui-ci divergent en moins d’un an.

Le sélecteur liste les autres processus de cet environnement. Un processus ne peut pas s’appeler lui-même.

Conditions : quel chemin prend un branchement

Sélectionnez une connexion qui part d’un branchement et ouvrez sa Condition sous Code — une expression qui décide si le flux emprunte cette connexion. getVariable("approved") d’un côté, !getVariable("approved") de l’autre.

Elle n’est proposée que sur les connexions d’un branchement, et nulle part ailleurs. Une tâche n’a qu’une sortie : une condition y serait une question à une seule réponse.

Une condition ne peut que lire. Elle décide d’un chemin, et le moteur peut la poser plus d’une fois : une condition qui modifierait quelque chose rendrait le processus dépendant du nombre de fois où elle a été posée — l’éditeur ne vous propose pas les mots pour le faire.

À qui va une tâche

Une tâche utilisateur a une ligne Attribué à sous Code : une expression qui répond à la question de savoir qui doit s’en charger.

Vous voulez	Écrivez
Quiconque détient un rôle	role("Manager")
Une personne précise	user("a.khan")
Une équipe	team("Finance")
La personne qui a démarré le processus	instanceStartedBy()

C’est une expression plutôt qu’un sélecteur, à dessein : les attributions qui valent la peine d’être écrites sont celles qu’un sélecteur ne sait pas exprimer — l’approbateur correspondant au montant d’une variable, le responsable de la personne qui a fait la demande.

Seule une tâche utilisateur en a une. Une tâche de service est réalisée par la plateforme, il n’y a donc personne à qui la confier.

Une étape sans expression se rabat sur le Rôle de son couloir, ce qui est le cas ordinaire : n’écrivez l’expression que là où une étape diffère du reste du couloir.

Attendre, et être en retard

Un minuteur : attendre l’horloge

Dessinez un Minuteur là où le processus doit simplement attendre. Personne n’a rien à faire : l’exécution s’arrête là et repart d’elle-même.

Réglez Se déclenche sur Après une durée et renseignez Attendre : un nombre et une unité choisie à côté — 3 Jours, 4 Heures, 90 Minutes.

Un minuteur sans durée n’attend pas — il arrête l’exécution. C’est le seul réglage d’un processus qui n’a aucune valeur par défaut raisonnable : se déclencher immédiatement transformerait en silence une attente en absence d’attente, si bien que le chemin s’arrête et que l’historique de l’exécution indique « … ne précise pas quand il se déclenche ». Si un minuteur que vous avez dessiné ne se déclenche jamais, c’est la première chose à vérifier.

Les mois et les années ne sont pas proposés, à dessein. Un mois compte 28 jours en février et 31 en mars : une attente exprimée ainsi représenterait un nombre d’heures différent selon le moment où elle commence. Demandez 30 jours.

Pour qui lit le document

La durée est stockée sous forme de durée ISO-8601 — P3D, PT4H, PT90M — ce que lit le moteur et ce que doit indiquer un processus écrit à la main ou généré par une IA. Vous ne la saisissez jamais ; le nombre et l’unité constituent tout le champ. Une durée écrite à la main en deux unités (PT4H30M) s’ouvre comme la même durée en une seule (270 Minutes).

Choisissez plutôt À un moment fourni par le code quand le moment dépend des données — la date de l’enregistrement, une variable que quelqu’un a renseignée. Écrivez alors l’expression sous Code ; elle peut renvoyer soit un moment, soit une durée.

Une échéance : quand une étape doit être terminée

Sélectionnez une tâche utilisateur et renseignez Échéance dans — le même couple nombre et unité que le minuteur. Le décompte commence au moment où la tâche apparaît dans la liste de quelqu’un — et non quand il l’ouvre — si bien qu’une tâche créée le vendredi après-midi ne gagne pas discrètement le week-end.

La personne voit Échéance … sous la tâche dans sa liste, et une fois le moment passé, la mention passe au rouge et devient Échue …. À côté, En attente indique depuis combien de temps la tâche est là.

En cas de retard indique ce que fait le processus :

Choix	Ce qui se passe
Marquer en retard	Rien ne bouge. La tâche est visiblement en retard dans la liste, et l’historique de l’exécution l’enregistre.
La proposer aussi au niveau supérieur	La personne désignée par l’escalade du couloir se la voit proposer aussi. Celle qui l’avait déjà la garde — une personne de plus peut agir, et on ne retire rien à quelqu’un qui était peut-être sur le point de terminer.
Décider automatiquement	Le processus appuie à leur place sur l’un des boutons propres de la tâche. Choisissez lequel sous Décider comme.

Décider automatiquement utilise les issues propres de l’étape : le schéma montre donc déjà où va ensuite le processus — il n’existe pas de seconde sortie invisible de l’étape. « Si personne n’approuve sous trois jours, considérer comme rejeté » s’écrit en choisissant Décider automatiquement puis Rejeter.

Laissez Échéance dans vide pour une étape sans échéance, ce qui est le cas de la plupart — effacer le nombre est ce qui retire une échéance.

Observez sans attendre un jour

Pendant la construction, réglez les durées sur une minute ou deux, publiez et lancez une exécution : l’escalade, l’attente et la décision automatique se produisent toutes sous vos yeux dans l’historique de l’exécution. C’est ainsi qu’est livré bpms-deadlines-and-timers, et c’est la seule chose irréaliste de cet exemple.

Code : ce qui s’exécute, et ce qui est calculé

Sélectionnez une tâche et vous obtenez sa liste Code — tout ce qui, dans cette étape, est écrit en BS Lang. Sélectionner une ligne ouvre la page de code.

Les quatre premières sont les moments auxquels elle peut réagir :

Emplacement	Quand il s’exécute
À l’entrée	Le processus atteint cette étape.
À l’attribution	La tâche a un destinataire — tâches utilisateur uniquement.
À la fin	Cette personne la marque comme terminée — tâches utilisateur uniquement.
À la sortie	Le processus quitte cette étape, quel que soit le chemin pris.

La racine du processus a les trois siens, sur le même modèle : Au démarrage, À la fin et À l’annulation. Au démarrage est l’endroit où vous donnez sa première valeur à une variable.

En dessous, sur une tâche utilisateur, se trouve ce qu’elle calcule plutôt que ce qu’elle exécute : Attribué à, Enregistrement, et une ligne par paramètre, nommée d’après le paramètre. Ils figurent dans la même liste parce qu’ils sont de même nature — un morceau de BS Lang appartenant à cette étape — et qu’une seule liste, c’est un seul endroit où chercher « qu’exécute cette étape ? ».

La liste indique quelles lignes contiennent déjà quelque chose, pour que vous voyiez d’un coup d’œil où se trouve le travail.

Un branchement a À l’entrée et À la sortie, et aucun emplacement qui choisisse un chemin.

• À l’entrée s’exécute dès que le processus arrive, avant qu’une condition soit posée. C’est là qu’un branchement fait ses calculs : calculez la réponse une fois, placez-la dans une variable, et laissez chaque condition la lire. Six tranches de montant donnent alors six conditions courtes plutôt que six copies du calcul.
• À la sortie s’exécute une fois un chemin choisi. Il ne s’exécute pas quand aucune condition n’était vraie — rien n’est sorti, il n’y a donc pas eu de sortie.
• La décision reste sur les connexions. Il n’existe délibérément aucun code qui choisisse une sortie : un schéma dont le branchement est décidé à un endroit que vous ne voyez pas est un schéma qui ment sur ce que fait le processus.

La page de code

Elle occupe tout l’éditeur et porte la liste des emplacements sur le côté, si bien que passer d’un moment à l’autre d’une tâche ne demande qu’un clic. L’œil dans son en-tête liste tout ce que vous pouvez appeler depuis cet emplacement — ce qui n’est pas partout pareil : une condition et un Attribué à ne peuvent que lire, un gestionnaire peut modifier des choses, et seul Attribué à se voit proposer user(), role() et team().

Il n’y a pas de bouton Enregistrer sur la page de code. Enregistrer dans la barre de titre est le seul, et il enregistre tout le processus.

remarque

Enregistrer un script ne l'exécute pas. Les variables, les conditions, les affectations et les scripts sont stockés avec la conception et vérifiés pendant que vous les écrivez ; ils s'exécutent une fois le processus publié et une exécution démarrée.

Problèmes : ce qui manque encore

Dans le coin du canevas, une barre indique combien de problèmes a le processus. Ouvrez-la pour voir la liste ; sélectionnez une ligne et le concepteur vous emmène à l’élément concerné — le nœud, la connexion ou la racine du processus.

Elle vérifie ce que le moteur exigera :

• exactement un Début, et au moins une Fin ;
• aucune connexion n’entre dans un Début ni ne sort d’une Fin, puisqu’une exécution commence à l’un et se termine à l’autre : elle ne serait jamais empruntée ;
• aucune étape que le flux ne puisse jamais atteindre, et aucune qu’il ne puisse jamais quitter ;
• une condition sur chaque connexion qui part d’un branchement, et au moins deux sorties par branchement ;
• au moins deux sorties d’une division et deux entrées d’une jonction, et le même nombre de chaque ;
• chaque variable nommée par un script est déclarée, et chaque ligne de variable a un nom ;
• chaque script est analysable.

Rien ici ne vous bloque. Un processus à moitié dessiné signale une page de problèmes et s’enregistre parfaitement — c’est tout l’intérêt de le dessiner. La liste vous permet de savoir ce qui reste à faire, et c’est la même liste que la plateforme appliquera quand un processus sera publié pour être exécuté.

Un mot sur deux d’entre eux. Le panneau indique si un script est analysable ; savoir s’il peut appeler un nom en particulier relève de l’éditeur de code, qui le souligne pendant que vous tapez en fonction de ce que cet emplacement peut voir. Et les divisions et jonctions sont comptées, pas appariées une à une — un processus qui se divise plus souvent qu’il ne se rejoint garde un chemin en cours alors qu’il devrait être terminé, et c’est presque toujours l’erreur.

Organisation automatique

Affichage → Organisation automatique range le schéma de gauche à droite, dans l’ordre du flux, en gardant chaque nœud dans son propre couloir. Elle déplace les nœuds horizontalement et retrace les connexions ; elle ne fait jamais passer le travail d’une personne à une autre.

Générer avec l’IA

Générer avec l’IA décrit un processus en mots et le dessine. Ce qui revient est validé avant d’atteindre le canevas, exactement comme un fichier importé — un schéma généré qui ne tient pas debout est donc refusé plutôt que dessiné.

Elle se corrige avant d’abandonner. Quand ce qui revient ne tient pas debout, la plateforme le renvoie directement au modèle en nommant le problème, plutôt que de vous demander de corriger une erreur de schéma que vous n’avez jamais écrite. Elle essaie jusqu’à trois fois, et le bouton affiche Correction… tentative 2 sur 3 pendant ce temps. Un échec ne vous est présenté qu’une fois la correction tentée, et ce qui vous est alors montré est la dernière chose qui n’allait pas.

Elle remplace ce qui se trouve sur le canevas, et n’enregistre pas. Regardez le résultat avant d’appuyer sur Enregistrer.

Vous décrivez le processus, et rien d’autre. Le modèle d’IA qui répond est configuré une fois pour toute la plateforme par un administrateur — il n’y a ni clé à coller ni fournisseur à choisir, et rien de ce que vous tapez ici ne va ailleurs qu’à ce modèle.

Si aucune IA n'est connectée, Générer le dit. Un administrateur du locataire en connecte une une seule fois, dans Paramètres → IA, pour toute l'organisation. Ce n'est pas quelque chose qu'un créateur active.

Enregistrer

Enregistrer, dans la barre de titre, écrit le processus. C’est le seul bouton Enregistrer : le schéma fait partie du composant, il n’y a donc aucun fichier à garder synchronisé et rien à penser à exporter.

Quitter avec des modifications non enregistrées demande d’abord confirmation — depuis Fermer, depuis le rail de navigation et depuis le bouton Précédent du navigateur.

Publier : enregistrer n’est pas livrer

Enregistrer conserve votre travail. Publier change ce qui s’exécute. Ce sont deux boutons parce que ce sont deux décisions, et la séparation existe pour une raison : un processus déjà en cours ne doit pas changer sous les pieds des personnes qui l’exécutent. Sans elle, corriger une faute de frappe à 16 h réécrirait le processus que suivait chaque instance en cours — y compris les étapes qu’elles avaient déjà franchies.

Le moteur ne lit donc que ce que vous avez publié, et une publication est une copie numérotée et figée du dessin tel qu’il était à cet instant.

La ligne sous le titre indique dans lequel des trois états vous vous trouvez :

Elle indique	Cela signifie
Pas encore publié	Rien n’exécute ce processus.
La version 3 est en cours d’exécution et correspond à ce que vous voyez	Vous regardez ce qui est en production.
La version 3 est en cours d’exécution. Vous avez des modifications non publiées	Vos modifications enregistrées ne sont pas encore en production.

Sélectionnez Publier et le brouillon devient la version suivante. Si vous avez des modifications non enregistrées, il les enregistre d’abord, car publier ce qui est à l’écran est le sens même du mot.

Quelques points à savoir :

• Publier un processus inchangé est refusé. Si rien n’a changé depuis la dernière publication, il n’y a rien à publier, et un historique rempli de versions identiques est un historique que personne ne peut lire.
• Il n’y a pas de dépublication. Une version que quelqu’un exécute peut-être n’est pas quelque chose à supprimer. Si vous voulez revenir en arrière, remettez le dessin précédent sur le canevas et publiez-le — l’historique reste intact, et c’est ce qui fait sa valeur.
• Les instances conservent la version sur laquelle elles ont démarré. Ce qui a commencé sous la version 2 se termine sous la version 2, quoi que vous publiiez pendant son exécution.

remarque

Publier ne démarre rien. Cela décide de ce qui s'exécute au prochain démarrage du processus, et les exécutions déjà en cours gardent la version avec laquelle elles ont commencé.

Publier attend que la liste des problèmes soit vide. Tant que le coin du canevas affiche quelque chose, le bouton est indisponible, et le survoler indique pourquoi. Un processus qui a des problèmes ne s’exécuterait pas ; auparavant, le publier enregistrait d’abord le dessin, puis était refusé.

Importer et exporter

Exporter en JSON télécharge le schéma sous forme de fichier .bpms.json — ce qui est sur le canevas en ce moment, modifications non enregistrées comprises, car le fichier sert à emporter un schéma ailleurs, et exporter la version de la semaine dernière alors que vous regardez celle de cette semaine est le genre de surprise que l’on ne découvre qu’à l’arrivée.

Importer du JSON en recharge un. Cela remplace ce qui est dessiné et n’enregistre pas : un import qui s’avère être le mauvais fichier s’annule en quittant l’écran sans enregistrer.

Le fichier est vérifié avant d’être chargé : la version, les couloirs, les nœuds, et le fait que chaque connexion relie bien deux nœuds existants. Un fichier qui échoue indique quel identifiant était erroné.

Dès qu’un processus voyage dans sa solution, l’import et l’export servent à déplacer un schéma entre environnements à la main — une commodité, pas la façon dont le travail est promu. Cela, c’est la solution.

Exporter une image

Exporter → Image (PNG) et Image (SVG) dessinent le schéma tel qu’il apparaît — pour un document, une diapositive ou un mur. Ni l’un ni l’autre n’est le processus : ils ne peuvent pas être réimportés.

Dépannage

• Ma variable n’apparaît pas dans les suggestions de l’éditeur. — une variable sans nom n’est proposée nulle part. Donnez un nom à la ligne, et quittez le champ pour que le nom soit validé.

• Je ne trouve pas setVariable dans une condition. — une condition ne peut que lire ; voir plus haut. Placez la modification dans le script d’une tâche.

• Un script que j’avais écrit sur une tâche a disparu. — changer le type d’une tâche change ses moments. Transformez une tâche utilisateur en tâche de service, et ses À l’attribution et À la fin ne sont plus proposés ; un schéma importé qui les contient les perd.

• « Ce fichier n’est pas un JSON valide, il n’a donc pas pu être importé. » — le fichier est tronqué ou n’est pas du tout un schéma.

• « Ce fichier n’est pas un schéma de processus valide : … » — le détail nomme l’identifiant erroné : un nœud dans un couloir absent du fichier, une connexion vers un nœud qui n’existe pas.

• Enregistrer indique que le schéma n’est pas valide. — la même vérification s’exécute avant l’enregistrement. Corrigez le nœud ou la connexion qu’elle nomme ; le schéma à l’écran n’est pas perdu.

• Un nœud a sauté quand j’ai ouvert le processus. — un nœud qui se trouvait hors de son couloir y est ramené à l’ouverture. Le couloir d’un nœud, c’est qui fait le travail : les deux ne sont jamais autorisés à diverger.

• L’organisation automatique n’a rien fait. — elle organise selon le flux, elle a donc besoin de connexions. Un schéma de nœuds non reliés n’a aucun ordre dans lequel se ranger.

• Le panneau des problèmes indique qu’une étape « ne mène nulle part ». — aucune Fin n’est accessible depuis elle. Reliez-la à la suite, ou à quelque chose qui en atteint déjà une.

• Il indique que mon script n’est pas analysable, alors que l’éditeur de code semblait correct. — le panneau vérifie chaque script du processus, y compris ceux que vous ne regardez pas. Sélectionnez la ligne pour être conduit au nœud, puis ouvrez l’emplacement qu’elle nomme.

• « Aucun fournisseur d'IA n'est configuré. Ouvrez Paramètres → IA pour en connecter un. » — l'organisation n'a pas encore de connexion à une IA. Un administrateur du locataire la connecte une fois, dans Paramètres → IA, pour tout le monde.

• « L’IA a répondu sans schéma. » — le modèle a répondu en prose au lieu d’un processus. Décrivez les couloirs et les étapes plus simplement et générez à nouveau ; rien n’est perdu sur le canevas.

Scénarios associés

• Créer un processus.
• Ajouter un composant à une solution.