1. Preamble
Ce document présente le fonctionnement des workflows Camunda® de validation dans 
Project Monitor, du point de vue utilisateur et du point de vue conception.
Il s’adresse aux consultants qui doivent mettre en place des workflows de validation dans l’application.
WorkflowsIl est possible de configurer des workflows de validation dans Project Monitor. Pour ce faire, il faut qu’un add-on soit activé.
Le fichier contenant le code d’un workflow, et qui est chargé dans Project Monitor doit avoir pour extension .bpmn
Editorial agreement
Term | Description |
PM | |
WF | Workflow - Process |
JPDL file | Fichier “text” contenant le code d’un workflow de validation chargé dans Project Monitor afin de pouvoir être utilisé par l’application. Ce fichier a pour extension *.jpdl.xml |
BPMN file | Fichier créé à partir du modeler Camunda® contenant le code d’un workflow de validation, chargé dans Project Monitor afin de pouvoir être utilisé par l’application. Ce fichier a pour extension *.bpmn |
API | Application Programming Interface |
REST | Representation State Transfer |
HTTP | HyperText Transfer Protocol |
Architecture principle
The new Camunda® workflow engine lets you define workflows according to the BPMN (Business Process Model and Notation) standard.
It is based on the use of webservices.
Les API que l’on peut appeler dans le modeler Camunda® sont répertoriées dans la page 
Webservices memo selon les standards suivants :
- the principle of REST (Representational State Transfer) architecture,
- le protocole HTTP (Hyper Text Transfer Protocol),
- JSON (JavaScript Object Notation) data format.
Test tools
To ensure that each webservice used in the Camunda® modeler is correct, it is necessary to test the requests beforehand.
Several REST API-type tools are available for this purpose:
- Rest Client (Mozilla Firefox ®)
- Postman
2. General information
Technical architecture
To migrate a client environment to the new Camunda® workflow engine, it is necessary to deploy Camunda® on the application server.
La procédure de déploiement est en cours de rédaction !
Modeler Camunda®
Camunda® modeler is required to generate bpmn files 👇
https://camunda.com/download/modeler/
3. Workflow Camunda®
Camunda® vs JPDL
Camunda® permet de reprendre la quasi totalité des actions de workflow existantes dans Project Monitor à ce jour.
What determines whether or not an existing customer can activate the add-on is :
- SaaS / On premise hosting mode
- Le périmètre fonctionnel du workflow JPDL
Action | Description | JPDL | Camunda® |
Trigger | Automatic on modification status | ✔ | ✔ |
Manual on action user | ✔ | ✔ | |
Update | The status planning object | ✔ | ✔ |
The values ofattribute | ✔ | ✔ | |
status Project | ✔ | ✔ | |
Visit status document | ✔ | ✔ | |
Notify | Send tasks by email | ✔ | ✔ |
Packaging | Check the scheduling budget | ✔ | ✔ |
Multiple validation | ✔ | ✔ | |
Multi-factor condition "if phase on status AND task refused, then...". | ✔ | ✔ | |
View | Workflow | ❌ | ✔ |
Advances in proceedings | ❌ | ✔ |
4. Project Monitor avec Camunda®
Principes du workflow dans Project Monitor
Les principes du workflow Project Monitor ne changent pas fondamentalement, la migration vers Camunda® a été pensée de manière ISO à JPDL.
- Aussi, le workflow se déclenche sur le statut de projet, le statut de document ou manuellement.
- Il est hérité du gabarit de création du projet. Il n’est pas possible d’ajouter un workflow à un projet sans passer par l’insertion de gabarit. À l’inverse, tous les projets ayant un gabarit portent le workflow de ce gabarit.
- Il avance par validation de tâche.
Selon les webservices publics, il sera même possible d’ajouter des actions à ce jour inexistantes dans JPDL, comme la création de nouveaux objets dans le projet par exemple.
Pre-configuration
Add-on activation
L’activation de l’add-on se fait au niveau MM > Plateformes.
Dans la liste des add-ons, activer l’add-on Workflow.
Technical user
Pour que Camunda® et Project Monitor puissent fonctionner, il faut créer un utilisateur technique avec les droits suffisants sur les actions de WF à mener.
It is therefore necessary to assign the user a general role with extended rights.
Code concordance
Il est nécessaire pour assurer que le WF soit compatible avec Project Monitor que les codes utilisés dans les webservices correspondent à ceux de Project Monitor :
- Code role
- List value code status task
- Code list value type of task
- List value code status project/milestone/phase
- ...
5. Les actions workflow Camunda®
The Camunda® workflow file must be created in the Camunda® modeler.
Each WF must contain at least :
- un event start,
- une task,
- un event end.
Each WF step is linked to the next by a "flow".
Modelling structure
Camunda® modeler is made up of :
- Action de WF
- Schéma
- Panneau de propriétés
Only the followingaction buttons can be used in v6.5.2:
- Event start
- Flow
- Task
- Gateway
Créer un fichier BPMN
Pour créer un nouveau fichier de workflow, deux solutions :
- Créer un nouveau fichier et cliquer sur le bouton
BPMN diagram (Camunda Platform): - Utiliser un fichier BPMN existant ci-dessous 👇 en l’ouvrant depuis
Fichier>Ouvrir fichier
Lors de la création du fichier BPMN, le panel de properties est accessible sur la droite.
Il faut renseigner les éléments structurants suivants qui seront ensuite repris dans Project Monitor :
Camunda® | |
id | code |
Name | Wording |
Le nom du fichier BPMN à la sauvegarde n’est pas une entrée essentielle car non reprise dans Project Monitor.
En revanche, elle permet de gérer les versions dans votre environnement en développement.
When importing a WF, it's the id that identifies whether it's a new WF or a new version of a WF.
Create a action
Actions are created by Drag&Drop.
Simply enter action in the menu and click and drag into the "schematic" area.
Idéalement on procédera en deux étapes :
- Full WF modeling
- Setting each action
Once slid into the schematic, each action will have its own settings menu 👉
When you click on the key, the menu appears, allowing you to determine the nature of theaction.
The "properties" panel opens for setting parameters.
Each ofaction 's settings is detailed below.
Create an event start
Chaque WF doit commencer par un évènement. Il est donc nécessaire de créer un Event start 👉
Create a task
Le principe du WF de Project Monitor est de travailler avec des tâches de WF, aussi il est nécessaire de matérialiser chaque étape à valider par une Task 👉
There are several types of task :
- Les tâches de WS
Service task - Les tâches user
User task
Service task
Le service task crée la tâche de WF Project Monitor.
It is represented by the cogwheel icon.
It uses webservices and WF variables in the properties panel.
General
Id | Id of task |
Name | Name of the task |
Implementation | Connector |
Connector
Variable name | Variable assignment type | Variable assignment value | Value | |
Connector id | http-connector | String or Expression | #NA | |
Input parameters | headers | Map | Accept | application/json |
Content-type | application/json | |||
X-PM-API-ID (remplace X-PM-API-LOGIN | user id | |||
X-PM-API-PASSWORD | user pw | |||
method | String or Expression | POST | ||
url | String or Expression | url | ||
payload | String or Expression | BeanTacheEntree | Voir liste de variables |
Liste des variables Payload
The following variables are called in the payload (webservice) to execute WF tasks on the project and the project's WF instance:
"projet": { "id": #{execution.getVariable('projectId')}}—> récupère l’id projet de l’instance en cours"idInstance":"#{execution.getProcessInstanceId()}”—> récupère l’id de l’instance de WF"id": #{execution.getVariable('documentId')}—> récupère l’id document de l’instance en cours"idWorkflow":"validation_statut_tache1”—> définit la user task en attente de l’exécution de la tâche#{statusCode=='CODE_STATUT_TACHE'}#{execution.getVariable('projectLabel')}—>récupère le libellé du projet"code" : "CODE-DONNE-POUR-LA-TACHE"—> Permet de déterminer un code pour la tâche"parent" : {"code":"CODE-DONNE-POUR-LA-TACHE-PARENTE"} —>Permet de rattacher une tâche à une tâche parente"listeRolesParticipants" : ["ARBITRE_DEMANDE","ROLE_CONTRIBUTEUR"]—> Permet de définir une liste de code rôle (exemple : pouvoir notifier plusieurs rôles et participants sur une tâche)#{execution.getVariable('userCamundaId')}—> Récupère l’id de l’utilisateur qui exécutera le processus (à renseigner dans le header X-PM-API-ID)#{execution.getVariable('codeVar1')}—> Permet de récupérer une variable viaProject Monitor (par exemple le code d’un gabarit à appliquer)
Liste des variables URL :
#{execution.getVariable('projectId')}/attributes/CODEATTRIBUT—> Permet de récupérer la valeur d’un attribut dans Camundahttp://localhost:#{execution.getVariable('port')}/monitorupgrade/tasks—> Permet d’exécuter le workflow depuis n’importe quel port (autre que le 8080)http://localhost:#{execution.getVariable('port')}/monitorupgrade/tasks/parent/#{execution.getVariable('objectId')}/status/#{execution.getVariable('codeVar1')}—> Permet de récupérer l’ID d’une tâche parente (#{execution.getVariable('objectId')}) et de lui appliquer le statut paramétré dans l’automatisation (#{execution.getVariable('codeVar1')})
Connector outputs d’une service task
Il est possible de configurer des “connector outputs” au sein d’une service task afin de recevoir des messages d’information ou d’erreur à l’exécution du web service présent dans un processus dans Project Monitor. Voici le paramétrage à appliquer sur chaque service task :
Process variable name | Assignment type | Format | Type | Script |
errorLabel | Script | JavaScript | Inline script | var statusCode = connector.getVariable('statusCode');
if (statusCode >= 400) {
var response = JSON.parse(connector.getVariable('response'));
if (response.message) {
response.message;
} else if (response.error) {
response.error;
} else if (response[0] && response[0].beanWsErreur && response[0].beanWsErreur.message) {
response[0].beanWsErreur.message;
}
} |
infosLabel | Script | JavaScript | Inline script | var headers = connector.getVariable('headers');
if (headers.get('X-Context-Info')) {
headers.get('X-Context-Info');
} |
warningsLabel | Script | JavaScript | Inline script | var headers = connector.getVariable('headers');
if (headers.get('X-Context-Warning')) {
headers.get('X-Context-Warning');
} |
taskId (uniquement dans une service task de type création de tâche | Script | JavaScript | Inline script | var response = JSON.parse(connector.getVariable('response'));
response[0].beanWsItem.id; |
User task
Le user task définit le paramètre d’écoute de la tâche, la plupart du temps le statut tâche et permet l’avancement du WF dans Project Monitor.
Elle se matérialise par l’icône User.
A task user task is always preceded by a service task.
Creating a flow
L’évènement flow sert à modéliser le chemin du process d’un évènement à un autre 👉
When the flow carries a WF decision, it is necessary to parameterize the status listener.
General
id | id |
Name | Name |
Standard condition | Expression |
Expression | #{statusCode=='status_TACHE_REFUSEE'} |
Create a gateway
A gateway can be used to create several WF paths.
Deux types de gateway fonctionnent :
- Exclusive gateway
An exclusive gateway makes it possible to determine several independent paths, each leading to a different end of the WF.
- Parallel gateway
A parallel gateway allows you to create several events or tasks in parallel, all converging towards a common event end.
Create an event end
Each flow in the process described must end with an event end.
Save WF file
Le nom de fichier sert à identifier les versions de WF, mais n’est pas utilisé par ailleurs dans Project Monitor.
Configurer les propriétés d’un fichier de workflow ou d’automatisation
À la création d’un fichier BPMN, il faut indiquer s’il sera utilisé comme un workflow ou une automatisation dans Project Monitor. Il faut modifier les propriétés du fichier BPMN dans un éditeur de texte (Notepad par exemple) ou via la fonction afficher au format XML dans Camunda®.
Sur la ligne 2, rechercher la valeur targetNameSpace et indiquer les variables suivantes en fonction du fichier BPMN paramétré :
targetNamespace="auto"→ le fichier est un fichier d’automatisationtargetNamespace="bpmn"→ le fichier est un fichier de workflow
Si le processus doit s’exécuter sur un type de déclencheur particulier, il est possible d’ajouter des extension properties au sein du fichier BPMN global. Il sera demandé de renseigner un nom et une valeur :
Voici toutes les options possibles d’éléments déclencheurs :
Name | Value | Description |
forManual | true | Déclenchement manuel uniquement |
forProject | true | Déclenchement sur statut projet uniquement |
forDocument | true | Déclenchement sur statut document uniquement |
forTask | true | Déclenchement sur statut tâche uniquement |
forTask-metastatus | terminated | Déclenchement sur statut tâche au méta-statut terminé uniquement |
forPhase | true | Déclenchement sur statut phase uniquement |
forMilestone | true | Déclenchement sur statut jalon uniquement |
forAttribute | true | Déclenchement sur valeur d’attribut uniquement |
extension properties n’est renseignée, alors le fichier BPMN s’exécutera sur tous les types de déclencheurs disponibles.Pour que le code variable ne soit plus renseigné manuellement dans Project Monitor, il est possible d’indiquer à Camunda® quel est l’élément concerné par la variable et quelle liste de valeur afficher.
Il suffit d’ajouter de nouvelles extension properties au sein du fichier BPMN :
Name | Value | Description |
codeVar1-objectDefinedType | code du thème à renseigner | Permet d’indiquer quel type d’attribut sera utilisé en tant que variable dans le paramétrage du processus (TACHE, PHASE, PROJET) |
codeVar1-attributeListCode | code de l’attribut à renseigner | Permet d'indiquer quel attribut sera utilisé dans la variable de paramétrage du processus. La liste associée à l’attribut s’affichera alors dans la propriété “objet unique” |
codeVar1-objectType | code de l’élément à renseigner | Permet d’indiquer quel objet sera utilisé en tant que variable dans le paramétrage du processus et permet de saisir le libellé de l’objet directement dans le paramétrage (GABARIT_PROJET pour afficher la liste des gabarits et rechercher dans la liste des gabarits projet) |
codeVar1-permission | code du droit à renseigner | Permet de vérifier si l’utilisateur qui paramètre le processus dispose des droits pour consulter la liste affichée en variable (la liste des gabarits projet par exemple) tout en prenant en compte les droits de cloisonnement sur la plateforme |
Exemple 1 :
L’automatisation Change the status tasks at status from phase/milestone est paramétrée comme suit :
targetNamespace=”auto”(propriété présente dans la version XML du fichier BPMN)- Extension properties :
forMilestone=trueforPhase=truecodeVar1-objectDefinedType=TASKcodeVar1-attributeListCode=STATUS
Ce qui veut dire que le fichier est une automatisation (targetNamespace=”auto”), qu’il ne peut se déclencher que sur le statut phase ou jalon (forMilestone and forPhase) et que la variable utilisée dans la propriété “objet unique” se basera sur un attribut de tâche (codeVar1-objectDefinedType = TACHE), qui porte le code STATUS, affichant ainsi la liste associée étant le statut tâche (codeVar1-attributeListCode = ETAT) :
Exemple 2 :
L’automatisation “Appliquer un gabarit” est paramétrée comme suit :
- targetNamespace=”auto” (propriété présente dans la version XML du fichier BPMN)
- Extension properties :
codeVar1-objectType = GABARIT_PROJETcodeVar1-permission = ACT_UTILISER_GABARIT_PROJET
Ce qui veut dire que le fichier est une automatisation (targetNamespace=”auto”), qu’il peut s’exécuter sur tous les déclencheurs disponibles, que la variable utilisée dans la propriété “objet unique” se basera sur la liste des gabarits de projet (codeVar1-objectType = GABARIT_PROJET) et vérifiera que l’utilisateur qui paramètrera l’automatisation possède bien le droit 
Using templates in projects tout en respectant le paramétrage de cloisonnement sur la plateforme (codeVar1-permission = ACT_UTILISER_GABARIT_PROJET) :
Créer un workflow conditionné : le cas Appliquer un gabarit
Il est possible de conditionner l’exécution de certains web services paramétrés dans un fichier BPMN via un tableau de décision, configurable dans un fichier DMN (Decision Model and Notation). Un fichier DMN présente un tableau permettant de modéliser des prises de décision et des règles métier via le langage FEEL (Friendly Enough Expression Language), basé sur la création d’expression au lieu de code spécifique.
Pour créer un workflow conditionné, il faudra avoir a minima une business rule task, des flows conditionnés et créer un fichier DMN en plus du fichier BPMN représentant le workflow.
Dans l’exemple ci-dessous, un gabarit sera appliqué en fonction des informations récupérées sur le projet (informations des attributs budget et ressource) :
Créer une service task pour récupérer les informations projet
Créer une service task permet de récupérer une information d’un attribut projet. Si l’instance décisionnelle doit récupérer plusieurs informations, créer autant de service task qu’il y a d’informations à récupérer. Ces service task doivent être positionnées soit successivement, soit entre deux parallel gateway.
General
Id | Id de la service task |
Name | Nom de la service task |
Implementation
Type | Connector |
Connector ID | http-connector |
Connector inputs
Variable name | Variable assignment type | Variable assignment value | Value |
headers | Map | Accept | application/json |
Content-type | application/json | ||
X-PM-API-ID | user id | ||
method | String or Expression | GET | |
url | String or Expression | url |
Connector outputs (sera utilisé dans le fichier DMN)
Process variable name | Nom de la variable (dans l’exemple budget_value et ressource_value) |
Assignment type | Script |
Format | JavaScript |
Type | Inline script |
Script | var response = JSON.parse(connector.getVariable('response'));
response; |
Créer une business rule task
La business rule task récupère les informations de décision et règles métier présentes dans le fichier DMN pour exécuter la bonne décision dans le processus.
Elle se matérialise par l’icône tableau.
General
Id | Id de la business rule task |
Name | Nom de la business rule task |
Output (pour renvoyer une erreur s’il n’y a pas de décision trouvée)
Process variable name | errorCode |
Assignment type | String or expression |
Expression | #{execution.getVariable('result')==null?'ERR_WORKFLOW_NO_DECISION':null} |
Implementation
Type | DMN |
Decision reference | ID de la decision |
Binding | Latest |
Tenant ID | |
Result variable | result |
Map decision result | Sélectionner la méthode de résultat à appliquer |
Créer un “flow” décisionnel
L’événement flow décisionnel sert à modéliser le chemin du process d’un événement à un autre en fonction du résultat trouvé dans un tableau décisionnel. Cela permet d’indiquer en cas de résultat nul ou non nul, le chemin à prendre pour continuer le workflow.
id | id |
Name | Name |
Standard condition | Expression |
Expression pour résultat non nul | #{execution.getVariable('result')!=null} |
Expression pour résultat nul | #{execution.getVariable('result')==null} |
Dans l’exemple ci-contre, le workflow appliquera le gabarit si tous les paramètres récupérés sont réunis pour exécuter une décision. Si les paramètres récupérés ne permettent pas d’exécuter une décision, alors le workflow prend fin.
Créer une service task pour exécuter la décision
General
Id | Id de la service task |
Name | Nom de la service task |
Implementation
Type | Connector |
Connector ID | http-connector |
Connector inputs
Variable name | Variable assignment type | Variable assignment value | Value |
headers | Map | Accept | application/json |
Content-type | application/json | ||
X-PM-API-ID | user id | ||
method | String or Expression | POST | |
payload | String or Expression | BeanTacheEntree | {
"projet": { "id": #{execution.getVariable('projectId')}},
"template": {"code": "#{execution.getVariable('result').get('apply_template')}"},
"insert": false
} |
url | String or Expression | url |
Connector outputs
Process variable name | Assignment type | Format | Type | Script | |
errorLabel | Script | JavaScript | Inline script | var statusCode = connector.getVariable('statusCode');if (statusCode >= 400) {var response = JSON.parse(connector.getVariable('response'));if (response.message) {response.message;} else if (response.error) {response.error;} else if (response[0] && response[0].beanWsErreur && response[0].beanWsErreur.message) {response[0].beanWsErreur.message;}} | var statusCode = connector.getVariable('statusCode');
if (statusCode >= 400) {
var response = JSON.parse(connector.getVariable('response'));
if (response.message) {
response.message;
} else if (response.error) {
response.error;
} else if (response[0] && response[0].beanWsErreur && response[0].beanWsErreur.message) {
response[0].beanWsErreur.message;
}
}
|
infosLabel | Script | JavaScript | Inline script | var headers = connector.getVariable('headers');if (headers.get('X-Context-Info')) {headers.get('X-Context-Info');} | |
warningsLabel | Script | JavaScript | Inline script | var headers = connector.getVariable('headers');if (headers.get('X-Context-Warning')) {headers.get('X-Context-Warning');} |
Créer un fichier DMN
Créer un fichier DMN permet de configurer un tableau de décisions à exécuter en fonction des règles établies.
Un fichier DMN a forcément un nom et un ID. Dans notre exemple, le fichier DMN va analyser les informations récupérées en amont des attributs budget et ressource pour vérifier s’il y a une règle qui répond à une décision à exécuter :
- Le gabarit “Projet standard” sera appliqué sur le projet en instance de workflow si le budget est supérieur à 50000€ et les ressources supérieures à 150 j/h
- Le gabarit “Cycle en V” sera appliqué sur le projet en instance de workflow si le budget est inférieur ou égal à 50000€ et les ressources inférieures ou égales à 150j/h
- Le workflow se terminera si aucune décision n’est trouvée (flow conditionnés sur le fichier BPMN)
Dans le cas de récupération de valeur d’attribut numérique, il faut paramétrer les colonnes du tableau de la manière suivante :
Expression | Reprendre le libellé du processus variable name du connector output de la service task de récupération de la valeur d’attribut (budget_value ou ressource_value) |
Expression language | feel |
Input variable | N/A |
Type | double |
Pour la définition de la décision à exécuter, voici le paramétrage :
Output name | Reprendre le code indiqué dans le payload de la service task exécutant la décision (apply_template) |
Type | string |
6. Fonctionnement dans Project Monitor
Une fois réalisée la modélisation du process dans le modeler Camunda®, il est possible de le charger dans Project Monitor.
However, it is necessary to ensure that the add-on has been activated.
Add-on activation
L’activation de l’Add-on se fait au niveau MM, connecté en savirage.
Dès que l’add-on est activé, plusieurs conséquences sont effectives dans Project Monitor :
JPDL | Camunda® |
The card is marked "depreciated". | La carte apparaît et est libellée “Workflow” |
JPDL files can no longer be uploaded to admin | Il est possible de charger les fichiers BPMN en admin |
WFs in progress can be completed | Camunda WFs will need to be combined with existing templates |
It will no longer be possible to associate JPDL WFs with templates. | |
Les WF jpdl resteront associés aux gabarits existants, il faudra les supprimer dès upload et association des fichiers BPMN existants |
Suggested checklist before activating the add-on:
Upload WF
L’administration des WF se fait de la même manière qu’avec les fichiers JPDL, depuis 
Administration > Paramétrage des modèles >Automatisations et workflows > Workflows.
Plusieurs WF peuvent être chargés dans Project Monitor. Plusieurs versions de WF peuvent être chargées au fur et à mesure de l’évolution des processus.
Versioning enables existing projects to complete all the steps in a process, even if the process has changed.
Camunda® provides the ability to view WF diagrams, instances in progress at each stage, and navigate to project instances.
Les fichiers DMN se charge de la même manière que les fichiers BPMN dans Project Monitor mais ne seront pas visibles dans l’administration de Project Monitor. Il faut se connecter à Camunda Cockpit pour visualiser le fichier DMN chargé dans Project Monitor.
Linking the WF to a template
The WF has been imported into the administration system, and must now be associated with a template.
This is the only way a project can inherit from an underlying WF.
Si le projet n’a pas été créé depuis le gabarit il est possible a posteriori d’appliquer unitairement ou en masse le gabarit aux projets. Il deviendra ainsi possible de déclencher le WF sur les projets existants.
Define a status trigger
When associating a WF with a template, it is possible to define the WF trigger mode on projects:
- manual release
- triggered by status project
- triggered by status document
- déclenchement par statut de tâche
- déclenchement par statut de phase
- déclenchement par statut de jalon
- déclenchement par valeur d’attribut
Il suffira alors de sélectionner la valeur de liste dans le sélecteur proposé :
Si le déclenchement se fait sur le statut tâche, phase ou jalon, alors il est possible de définir le type de tâche, phase ou jalon sur lequel le processus sera déclenché :
Si le déclenchement se fait sur le statut document, tâche, phase ou jalon, alors il est possible d’exécuter le processus sur le dernier élément déclencheur (par exemple, le gabarit sera appliqué lorsque tous les documents du projet seront validés) :
WF visualization
Il existe deux modes de visualisation des workflows :
- Visualization in the project
- Visualization in admin
Project visualization
Admin view
Each project has a diagram showing the progress of the process in the settings screen.
If several WFs are launched on the same project, an unfolded chevron is available to consult the appropriate diagram.
In the admin screen, each process version has its own schema. Each schema contains a number of items of information:
- The number of projects in each stage in the pink bubble
- Click on the bubble to filter on the step, and a potato chip is displayed to recall the criterion.
- A view "Project list" type is applied to the project list.
history workflows
Each workflow definition has its own history. This makes it possible to identify which creations/modifications/deletions have been carried out.