# Workflows dynamiques

> Un circuit de validation dont les statuts, les rôles et les transitions se définissent session par session, sans développement.

Un **workflow dynamique** est un circuit de validation que l'on définit soi-même, pour une session :
la liste des statuts, les rôles des intervenants et les passages autorisés d'un statut à l'autre. Là
où un circuit classique est livré avec l'application et ne se modifie pas, un workflow dynamique se
règle depuis la configuration de la session, sur le site web, et s'applique aussitôt à l'identique sur
le web et dans l'application ID ALL Site, y compris hors connexion.

Pour la notion de statut et de circuit de validation en général, voir
[Observations, statuts et circuits de validation](https://docs.idall.fr/site/concepts/observations-et-statuts/).

## Comment ça fonctionne

### Statuts, rôles et transitions

| Notion | Description |
| --- | --- |
| Statut | Une étape de la vie d'une observation (*À faire*, *En cours*, *Fait*…). Il a un nom technique, un libellé affiché et une couleur. |
| Statut initial | Le statut donné à une observation à sa création. Il n'y en a qu'un par workflow. |
| Levé final | Marque un statut de fin de traitement. Un workflow peut en avoir plusieurs. |
| Rôle | La casquette d'un intervenant sur la session (*Entreprise*, *Maîtrise d'œuvre*…). C'est le rôle qui décide des statuts qu'il peut attribuer. |
| **Sans rôle** | Le rôle implicite de tout utilisateur à qui aucun rôle n'est attribué : il consulte les observations, mais ne peut changer aucun statut. |
| Transition | Un passage autorisé d'un statut à un autre, réservé à un ou plusieurs rôles. Exemple : depuis *En cours*, un *Relecteur* peut passer à *Fait*. |

Un utilisateur peut faire passer une observation d'un statut A à un statut B **seulement** s'il existe
une transition de A vers B **et** qu'il possède l'un des rôles autorisés sur cette transition. C'est
pourquoi, dans l'application, la liste **Statut** de la fenêtre **Éditer le statut** ne propose que
certains statuts, voire aucun (**Aucun statut disponible**).

Un rôle peut être attribué automatiquement selon le profil de l'utilisateur (réglage **Rôle par défaut
par profil** du workflow), ou à la main, utilisateur par utilisateur, dans la configuration de la
session.

### Le nom technique des statuts

Chaque statut a un **nom** technique, distinct de son libellé. Le libellé et la couleur peuvent changer
à tout moment ; le nom, lui, sert de repère stable :

- deux sessions dont les statuts portent le **même nom** sont considérées comme ayant le même statut,
  pour le filtre par statut et pour le déplacement d'observations ;
- le nom fixe la place du statut dans le diagramme du workflow : un nom commençant par `REFUS`
  s'affiche en haut, un nom commençant par `LEVE`, `VALID` ou `CLOTUR` en bas, et les statuts qui
  partagent un suffixe (`_ENT`, `_MOE`…) sont rangés dans une même colonne. Ce placement est purement
  visuel.

### Qui fait quoi

| Action | Qui | Où |
| --- | --- | --- |
| Changer le statut d'une observation | Tout utilisateur, selon son rôle | Web et application |
| Attribuer les rôles, activer les options du workflow, personnaliser libellés et couleurs, exporter la configuration | Administrateur de l'opération | Site web, configuration de la session |
| Créer ou modifier un workflow dynamique (statuts, rôles, transitions) | Administrateur disposant du droit **Gérer les workflows dynamiques** | Site web, éditeur de workflow |
| Convertir le workflow d'une session existante en workflow dynamique | ID Capture | À demander au support |

Le droit **Gérer les workflows dynamiques** n'est pas accordé par défaut et un administrateur ne peut
pas se l'attribuer lui-même : il est ouvert au cas par cas par ID Capture, à demander au support.

### Convertir une session existante

Une session déjà en cours, qui contient des observations, peut passer d'un circuit classique à un
workflow dynamique équivalent, par exemple pour ajouter une transition qui manque ou débloquer un rôle.
La conversion reprend les statuts, les rôles et les transitions du circuit d'origine, et **les
observations gardent leur statut**. Elle est **irréversible** : la session ne peut plus revenir à son
circuit d'origine. Cette opération est réalisée par ID Capture, à demander au support. Une fois la
session convertie, son workflow se modifie comme n'importe quel workflow dynamique.

### La session des non-conformités

Les fiches de conformité et les fiches de contrôle créent leurs non-conformités dans une session
dédiée. Cette session peut utiliser un workflow dynamique, à condition de respecter une convention de
**noms techniques**, car c'est ce nom qui indique à la fiche quel statut lève un point :

| Élément | Nom technique | Sens |
| --- | --- | --- |
| Statut qui lève un point | `FIXED_0`, `FIXED_1`, `FIXED_2`… | Le chiffre est le niveau : `FIXED_0` = levé au premier niveau, `FIXED_1` au deuxième… |
| Statut qui refuse un point | `REFUSED_0`, `REFUSED_1`… | Même logique de niveau. |
| Rôle d'un niveau | `ACTOR_0`, `ACTOR_1`… | Un rôle par niveau utilisé dans les statuts. |
| Statut initial | `INITIAL` (recommandé) | — |

Seuls les noms techniques sont imposés : libellés, couleurs, transitions et rôles par défaut restent
libres, et l'on peut ajouter des statuts ou des rôles hors convention (une étape « En cours d'analyse »,
un rôle observateur), qui ne lèvent simplement jamais un point.

Un point n'est levé que si **le niveau du statut atteint celui de l'auteur de la fiche** : un point
relevé par la maîtrise d'œuvre (niveau 1) n'est pas levé par un statut `FIXED_0` posé par l'entreprise.
La fiche se clôture quand tous ses points sont levés.

:::caution
La case **Levé final** ne lève pas un point : elle marque la fin du cycle, utilisée pour la clôture
des campagnes et les statistiques du plan de contrôle. La cocher sur un statut intermédiaire fausse les
statistiques et peut clôturer une campagne trop tôt.
:::

### Réinitialisation au changement d'entreprise

L'option **Réinitialisation du statut lors du changement d'entreprise affectée**

remet une observation à son statut initial quand on change l'entreprise qui doit la traiter, et ajoute
au **Suivi** le commentaire **Statut réinitialisé lors de la réaffectation d'entreprise**. Sur un
workflow dynamique, elle est **désactivée par défaut** : c'est à l'administrateur de l'activer s'il
veut ce comportement.

### Libellés et couleurs personnalisés par session

Le workflow définit le libellé et la couleur de chaque statut. Une session peut les personnaliser
(tableau **Label et couleurs des statuts**) : la valeur personnalisée s'affiche alors à la place de
celle du workflow, sur le web comme dans l'application. Une valeur personnalisée est marquée
**personnalisé** (libellé) ou **personnalisée** (couleur), et peut être ramenée à celle du workflow,
statut par statut ou d'un coup avec **Tout réinitialiser**.

À savoir : tant qu'une personnalisation existe, modifier le libellé ou la couleur dans le workflow ne
change rien à l'écran pour ce statut. Réinitialisez la personnalisation pour que la valeur du workflow
s'applique.

### Filtrer sur plusieurs sessions

Quand la liste des observations affiche plusieurs sessions, le filtre **Statuts** propose les statuts
de toutes les sessions sélectionnées. Cocher un statut ne retient que les observations des sessions où
ce statut existe réellement : deux statuts différents de deux workflows dynamiques ne sont plus
confondus. Pour qu'un statut se filtre d'un bloc sur plusieurs sessions, donnez-lui le même nom
technique dans chacune.

### Déplacer ou copier entre sessions

Lors d'un déplacement vers une autre session avec **Garder les statuts** coché, ou d'une copie, le
statut de chaque observation est recherché **par son nom technique** dans le workflow de destination :

- s'il existe, l'observation le garde ;
- sinon, elle repart du statut initial de la destination, et le **Suivi** l'indique (**Statut
  réinitialisé lors du déplacement de session : aucun statut équivalent dans le workflow de
  destination**, ou **Statut réinitialisé lors de la copie : …**).

Sur le web, un avertissement prévient avant l'opération : **Certains statuts n'ont pas d'équivalent dans
le workflow de destination et seront réinitialisés au statut initial.**

## Questions fréquentes

### Pourquoi je ne vois pas le statut que j'attends dans la liste ?

Aucune transition ne mène de ce statut-là au statut voulu pour votre rôle, ou vous êtes **Sans rôle**
sur cette session. Demandez à l'administrateur de l'opération de vérifier votre rôle dans la session,
ou d'ajouter la transition dans le workflow.

### J'ai modifié le workflow, mais rien n'a changé pour les utilisateurs.

Après **Valider** dans l'éditeur, il faut encore **enregistrer la session** : un message le rappelle
(**Configuration modifiée — pensez à enregistrer la session pour appliquer la modification.**). Dans
l'application, les changements arrivent à la synchronisation suivante.

### J'ai changé le libellé d'un statut dans le workflow, mais l'ancien s'affiche toujours.

La session a une personnalisation pour ce statut, qui prend le dessus. Supprimez-la dans le tableau
**Label et couleurs des statuts** (voir
[Paramétrer le circuit de validation d'une session](https://docs.idall.fr/site/guides/workflows/parametrer-le-circuit-de-validation-d-une-session/)).

### Le statut de mon observation est revenu au début après un changement d'entreprise.

L'option **Réinitialisation du statut lors du changement d'entreprise affectée** est active sur cette
session. Le **Suivi** de l'observation l'indique. Seul l'administrateur de l'opération peut la
désactiver.

### Une fiche de conformité ne se clôture jamais, alors que ses non-conformités sont traitées.

Le statut atteint par les non-conformités n'est pas un statut qui lève un point (nom `FIXED_…`), ou son
niveau est inférieur à celui de l'auteur de la fiche. Vérifiez les noms techniques des statuts et les
rôles de niveau dans le workflow de la session des non-conformités.

### L'enregistrement du workflow de la session des non-conformités est refusé.

Deux contrôles s'appliquent à cette session : il faut au moins un statut nommé `FIXED_0`, `FIXED_1`…,
et un rôle `ACTOR_<n>` pour chaque niveau utilisé par les statuts. Le message indique ce qui manque.
Le plus simple est de faire convertir la session depuis son circuit d'origine : la convention est alors
respectée d'office.

### Peut-on revenir au circuit d'origine après une conversion ?

Non, la conversion est définitive. En revanche, le workflow dynamique obtenu se modifie librement.

## Voir aussi

- [Configurer un workflow dynamique](https://docs.idall.fr/site/guides/workflows/configurer-un-workflow-dynamique/)
- [Paramétrer le circuit de validation d'une session](https://docs.idall.fr/site/guides/workflows/parametrer-le-circuit-de-validation-d-une-session/)
- [Observations, statuts et circuits de validation](https://docs.idall.fr/site/concepts/observations-et-statuts/)
- [Filtrer et organiser les observations](https://docs.idall.fr/site/guides/observations/filtrer-et-organiser-les-observations/)
- [Traiter plusieurs observations en une fois](https://docs.idall.fr/site/guides/observations/traiter-plusieurs-observations/)