Workflows

Les workflows transforment une colonne Status en un moteur de processus structuré. Au lieu de laisser n'importe qui changer librement le statut d'une ligne à tout moment, vous définissez exactement quelles transitions sont autorisées, qui peut les déclencher, quelles conditions doivent être remplies, et ce qui se passe automatiquement après qu'une transition est terminée. Cela rend les boards Copera comparables à des outils de processus dédiés comme Jira ou ServiceNow — intégrés directement dans votre espace de travail.

Activer un workflow

Les workflows se configurent individuellement par colonne Status. Pour en activer un :

1. Ouvrez votre board et accédez à la table qui contient la colonne Status que vous souhaitez contrôler.
2. Cliquez sur l'en-tête de colonne pour ouvrir les paramètres de la colonne.
3. Activez le commutateur Workflow.
4. L'éditeur visuel de workflow apparaît — un canevas montrant chaque statut comme un nœud et chaque transition autorisée comme une flèche dirigée entre les nœuds.
5. Définissez un Initial Status — le statut avec lequel les nouvelles lignes démarrent à leur création.

astuce

Lorsque vous activez le mode workflow pour la première fois, Copera propose des modèles prédéfinis pour des processus courants tels que Software Development (Backlog → In Progress → Code Review → QA → Done), IT Service Desk, HR Onboarding et Content Approval. L'application d'un modèle renseigne les statuts et transitions pour vous, vous offrant un point de départ solide à personnaliser.

Transitions de statut

Une transition définit un chemin autorisé entre deux statuts. Sans transition définie, le changement de statut est bloqué.

Transitions nommées

Chaque transition peut avoir un nom d'affichage qui apparaît dans l'interface lorsque les utilisateurs choisissent la prochaine action — par exemple, « Start Review », « Approve » ou « Send Back for Revisions ». Des noms clairs aident les membres de l'équipe à comprendre ce que chaque action signifie dans le contexte de votre processus.

Transitions spécifiques

Une transition spécifique relie un statut particulier à un autre. Vous les dessinez sur l'éditeur visuel en glissant d'un nœud de statut à un autre. Par exemple, connecter « To Do » directement à « In Review » crée une transition qui n'autorise que ce chemin.

Transitions globales

Une transition globale part de n'importe quel statut et va vers une cible spécifique. Elles sont utiles pour des actions qui peuvent toujours se produire quelle que soit la position d'une ligne dans le processus — par exemple, une transition « Cancel » qui déplace la ligne vers « Cancelled » depuis n'importe où, ou une transition « Escalate » qui fonctionne à n'importe quelle étape.

Commutateur « From Any Status »

Vous pouvez convertir n'importe quelle transition spécifique en transition globale directement depuis l'éditeur visuel. Lorsque vous cliquez sur une arête de transition et ouvrez le panneau latéral, cochez la case « From any status ». Cela définit la source sur « Any Status » et l'arête devient en pointillés, indiquant visuellement que la transition est accessible depuis tous les statuts. Décochez la case pour restaurer le statut source spécifique d'origine.

C'est particulièrement utile lorsque vous réalisez pendant la conception du workflow qu'une transition comme « Cancel » ou « Close » devrait être disponible à chaque étape — vous n'avez pas besoin de dessiner manuellement des arêtes individuelles depuis chaque statut.

note

Les utilisateurs peuvent toujours effacer une valeur de statut (la définir sur vide) indépendamment des règles de workflow. C'est intentionnel : effacer un statut ne compte pas comme une transition et n'est jamais bloqué.

Si la ligne n'a pas encore de statut actuel (première attribution après création), tout statut autorisé peut être défini librement. La validation du workflow ne s'applique que lors du passage d'un statut défini à un autre.

Conditions — Qui peut exécuter une transition

Les conditions contrôlent quels utilisateurs sont autorisés à déclencher une transition donnée. Toutes les conditions d'une même transition utilisent la logique AND — l'utilisateur doit satisfaire chaque condition listée.

Type de condition	Description
Role	L'utilisateur doit détenir l'un des rôles de board spécifiés.
User	L'utilisateur doit figurer dans une liste spécifique de personnes nommées.
Team	L'utilisateur doit appartenir à l'une des équipes spécifiées de l'espace de travail.
Row Owner	Seul l'utilisateur qui a créé la ligne peut déclencher cette transition.
Assignee	Seuls les utilisateurs actuellement attribués à la ligne (dans une colonne Users) peuvent la déclencher.

note

Les admins du board contournent les vérifications de conditions — ils peuvent déclencher n'importe quelle transition indépendamment des conditions. Cependant, les admins ne sont pas exemptés des validateurs. Les exigences de données s'appliquent à tout le monde.

Validateurs — Ce qui doit être vrai

Les validateurs vérifient si les données de la ligne satisfont les exigences avant que la transition soit autorisée à se poursuivre. Contrairement aux conditions, les validateurs s'appliquent à tous les utilisateurs, y compris les admins.

Type de validateur	Description
Field Required / Field Not Empty	Une colonne spécifiée doit avoir une valeur. Si elle est vide, la transition est bloquée.
Field Matches	La valeur de la colonne doit correspondre à un motif que vous définissez. Utile pour imposer des formats tels que des numéros de référence ou des codes.

Chaque validateur peut afficher un message d'erreur personnalisé afin que les utilisateurs sachent exactement ce qu'ils doivent renseigner avant que la transition puisse se poursuivre.

Champs requis

Au-delà des validateurs (qui vérifient les données existantes), une transition peut aussi demander à l'utilisateur de renseigner des champs au moment de la transition. Lorsque des champs requis sont configurés, une boîte de dialogue apparaît dès que l'utilisateur déclenche la transition, demandant ces valeurs avant que le changement de statut soit finalisé.

C'est utile lorsque vous souhaitez capturer du contexte à une étape spécifique — par exemple, exiger un champ « Rejection Reason » lors du passage à un statut « Rejected ».

Ce qui se passe en Kanban

Lorsque vous glissez une carte dans une nouvelle colonne en vue Kanban et que cette transition a des champs requis, la carte se déplace visuellement dans la nouvelle colonne et la boîte de dialogue de transition s'ouvre immédiatement pour collecter les valeurs manquantes. Le changement de statut se finalise une fois que vous avez renseigné la boîte de dialogue et confirmé.

C'est intentionnel --- vous obtenez une expérience de glisser-déposer fluide au lieu d'être bloqué en cours de glissement, et l'invite garantit que l'information est capturée avant que le déplacement soit validé. Si vous fermez la boîte de dialogue sans la compléter, la carte revient à sa colonne d'origine. (Si une transition n'est pas autorisée du tout, le glissement de la carte n'est simplement pas accepté et elle revient en place.)

Bon à savoir

L'invite de champs requis fait partie de l'interface Copera --- elle apparaît chaque fois que vous effectuez la transition via l'application, vous guidant pour renseigner les bons détails au bon moment.

Si vous avez besoin d'une garantie stricte qu'un champ ne peut jamais être laissé vide pour une transition (indépendamment de la façon dont le changement est effectué), ajoutez un Validateur de type Field Required ou Field Not Empty à cette transition, ou marquez le champ comme Required dans le comportement de champ par statut. Les validateurs et les règles required par statut s'appliquent à tout le monde, y compris les admins du board, ce sont donc les bons outils lorsque l'exigence est une règle stricte d'intégrité des données plutôt qu'une invite d'aide.

Portes d'approbation

Les transitions peuvent exiger l'approbation de personnes désignées avant que le changement de statut prenne effet. Lorsqu'un utilisateur déclenche une transition avec l'approbation activée, la ligne passe à un statut Pending Approval pendant que la demande d'approbation est traitée. Une fois la demande résolue (approuvée ou rejetée), la ligne passe au statut cible ou revient à son statut d'origine.

Types d'approbateurs

Vous pouvez désigner des approbateurs de quatre façons :

• Specific Users — Des personnes nommées qui doivent examiner la demande.
• Board Role — Toute personne détenant un rôle spécifié sur le board (tel que « Manager ») devient un approbateur.
• Row Owner — La personne qui a créé la ligne est l'approbateur.
• Column Based — Les approbateurs sont déterminés dynamiquement en fonction d'une valeur de colonne sur la ligne (voir ci-dessous).

Approbateurs conditionnels basés sur une colonne

L'approbation basée sur une colonne vous permet d'acheminer les demandes d'approbation vers différentes personnes selon une valeur de la ligne — sans créer de transitions ou de workflows séparés pour chaque cas.

Lorsque vous sélectionnez Column Based comme type d'approbateur, trois options de configuration apparaissent :

1. Condition column — Choisissez une colonne Dropdown (SELECT) de la table. La valeur actuelle de cette colonne sur la ligne détermine qui seront les approbateurs.
2. Mapping table — Pour chaque option de la colonne sélectionnée, attribuez un ou plusieurs approbateurs. Par exemple, si votre colonne « Department » a les options « RH », « Systems » et « Finance », vous pouvez mapper chaque département à son manager respectif.
3. Fallback approvers — Utilisateurs optionnels qui reçoivent la demande d'approbation lorsque la valeur de colonne de la ligne ne correspond à aucun mapping (ou que la colonne est vide).

Exemple — Approbation départementale multi-niveaux :

Supposons que vous ayez une colonne « Department » avec les options RH, Systems et Finance. Vous pouvez configurer deux transitions :

• Open → In Review : Approbation basée sur colonne sur « Department » — mappe RH vers Manager A, Systems vers Manager B
• In Review → Done : Approbation basée sur colonne sur « Department » — mappe RH vers Director X, Systems vers Director Y

Chaque transition résout indépendamment l'approbateur correct pour le département de la ligne. Cela crée un flux d'approbation multi-niveaux où les managers de département approuvent d'abord, puis les directeurs de département ensuite.

astuce

Le demandeur (la personne qui a déclenché la transition) est automatiquement exclu de la liste des approbateurs, même s'il correspond au mapping. Une personne ne peut pas approuver sa propre demande.

Politiques d'approbation

Politique	Comportement
ANY_ONE	Le premier approbateur à agir (approuver ou rejeter) résout la demande pour tout le monde.
ALL	Chaque approbateur désigné doit approuver. Un seul rejet rejette l'ensemble de la demande.

Statut Pending Approval

Lorsque l'approbation est activée sur une transition, le système crée automatiquement une option de statut Pending Approval sur la colonne. C'est un vrai statut — pas un état interne caché — ce qui signifie qu'il fonctionne de façon transparente avec chaque fonctionnalité de Copera :

• Filtres : Filtrez votre table pour ne voir que les lignes en attente d'approbation.
• Vue Kanban : Une colonne « Pending Approval » apparaît automatiquement, regroupant toutes les lignes en attente de décision.
• Timers SLA : Configurez des conditions SLA pour démarrer le chronométrage lorsqu'une ligne entre dans le statut pending et le mettre en pause à sa sortie.
• Automatisations : Créez des automatisations qui se déclenchent lorsque le statut d'une ligne passe à « Pending Approval » (par exemple, auto-attribuer un reviewer ou envoyer une notification personnalisée).
• Visibilité et règles de champ par statut : Configurez des overrides de visibilité et de comportement de champ spécifiquement pour l'état pending.

Le statut pending apparaît dans l'éditeur visuel comme un nœud distinct avec une bordure ambre et une icône sablier, facilitant son identification dans le graphe de workflow.

note

Les statuts pending approval sont gérés par le système. Ils ne peuvent pas être renommés ou supprimés manuellement — ils sont créés lorsque vous activez l'approbation sur une transition et nettoyés automatiquement lorsque vous la désactivez.

Fonctionnement du flux :

1. Un utilisateur déclenche une transition qui nécessite une approbation (par ex. Open → In Review).
2. La ligne passe immédiatement au statut Pending Approval.
3. Les approbateurs désignés reçoivent une notification.
4. Si approuvée : la ligne passe au statut cible (In Review).
5. Si rejetée : la ligne passe au statut de rejet configuré, ou revient au statut d'origine (Open) si aucun n'est défini.

Si vous avez plusieurs transitions avec l'approbation activée, chacune obtient son propre statut pending (par ex. « Pending: Manager Approval » et « Pending: Director Approval »), afin de pouvoir distinguer les différentes étapes d'approbation.

Gestion du rejet

Lorsqu'une transition est rejetée, vous pouvez configurer ce qui arrive à la ligne :

• La déplacer vers un statut spécifique (par exemple, un statut « Rejected » ou « Needs Revision »).
• Si aucun statut de rejet n'est configuré, la ligne revient au statut où elle se trouvait avant le déclenchement de l'approbation.

Notifications

Le demandeur et les approbateurs désignés reçoivent des notifications in-app et par e-mail. Les approbateurs sont notifiés lorsqu'une nouvelle demande d'approbation les attend ; le demandeur est notifié lorsque sa demande est approuvée ou rejetée.

Commentaires sur les décisions d'approbation

Les approbateurs peuvent ajouter un commentaire avec leur décision. Vous pouvez configurer une transition pour exiger un commentaire lors d'un rejet, garantissant que le feedback est toujours documenté.

note

Une seule demande d'approbation par ligne et par colonne Status peut être en attente à la fois. Si une demande est déjà en attente, aucune nouvelle transition ne peut être déclenchée jusqu'à sa résolution ou son annulation.

Fonctions post-transition

Les fonctions post-transition sont des actions qui s'exécutent automatiquement après qu'une transition se termine avec succès (y compris après qu'une approbation est accordée, le cas échéant). Elles s'exécutent sans aucune interaction utilisateur.

Fonction	Description
Set Field	Définir une colonne sur une valeur statique spécifique.
Copy Field	Copier la valeur d'une colonne dans une autre colonne de la même ligne.
Set Current Date	Écrire la date et l'heure actuelles dans une colonne de date — utile pour horodater le moment d'une transition.
Assign Current User	Ajouter l'utilisateur qui a déclenché la transition à une colonne Users.
Assign User	Ajouter une ou plusieurs personnes spécifiques à une colonne Users.
Clear Field	Retirer entièrement la valeur d'une colonne.
Send Notification	Envoyer une notification in-app à des utilisateurs spécifiques avec un message personnalisé.
Webhook	Envoyer une requête HTTP (POST, PUT ou PATCH) vers une URL externe, permettant l'intégration avec des systèmes tiers.

Vous pouvez ajouter plusieurs post-fonctions à une seule transition, et elles s'exécutent dans l'ordre listé.

Visibilité par statut

Vous pouvez contrôler quels utilisateurs sont autorisés à voir des lignes en fonction du statut actuel de la ligne. Cela se configure en cliquant sur un nœud de statut dans l'éditeur visuel et en ouvrant son panneau de paramètres.

Paramètre de visibilité	Description
Role-based	Seuls les utilisateurs avec des rôles de board spécifiques peuvent voir les lignes dans ce statut.
User-based	Seuls des utilisateurs nommés spécifiques peuvent voir les lignes dans ce statut.
Owner Can View	Le créateur de la ligne voit toujours ses propres lignes, même si les règles de visibilité les excluraient autrement. Activé par défaut.
Assignee Can View	Les utilisateurs attribués à la ligne la voient toujours. Activé par défaut.

note

Les admins du board voient toujours toutes les lignes indépendamment des règles de visibilité. Les paramètres de visibilité ne s'appliquent qu'aux membres réguliers et aux invités.

Comportement de champ par statut

Lorsqu'une ligne est dans un statut donné, vous pouvez remplacer le comportement des champs individuels. Cela se configure également depuis le panneau de paramètres du nœud de statut.

Comportement	Description
Editable	Comportement normal — le champ peut être lu et modifié. C'est le défaut.
Read-only	Le champ est visible mais ne peut pas être modifié. Les admins peuvent toujours modifier les champs en lecture seule.
Required	Le champ doit avoir une valeur. Cela s'applique à tous les utilisateurs y compris les admins — c'est une règle d'intégrité des données, pas une restriction de permission.
Hidden	Le champ n'est pas visible pour les non-admins et est exclu des réponses API. Les admins peuvent toujours voir et modifier les champs masqués.

Timers SLA

Les transitions de statut de workflow peuvent démarrer, mettre en pause et arrêter automatiquement les colonnes de timer SLA. Lorsqu'une ligne entre ou sort de statuts spécifiques, le timer réagit en conséquence — permettant le suivi automatique du temps passé par le travail à chaque étape. Consultez la page Suivi SLA pour les détails complets de configuration.

Conseils

• Commencez simple. Activez le workflow avec quelques transitions de base d'abord, puis ajoutez conditions, validateurs et portes d'approbation à mesure que votre processus mûrit.
• Utilisez l'éditeur visuel pour cartographier votre processus. Dessinez le flux sur le canevas avant d'ajouter des règles — il est bien plus facile de repérer les lacunes et les boucles visuellement.
• Les transitions globales sont idéales pour les exceptions. Les actions « Cancel », « Escalate » ou « Emergency Close » qui doivent toujours être disponibles depuis n'importe quel statut fonctionnent parfaitement comme transitions globales (from ANY).
• Combinez les portes d'approbation avec la visibilité par statut. Déplacez une ligne vers un statut « Pending Review » que seuls les reviewers peuvent voir, et exigez leur approbation avant qu'elle n'avance. Cela crée un processus de revue sécurisé et auditable.
• Utilisez les post-fonctions pour les mises à jour répétitives. Horodatez automatiquement les achèvements, attribuez la personne qui a fermé un ticket, et effacez les champs temporaires — sans que personne n'ait à s'en souvenir manuellement.
• Testez avec une ligne d'exemple. Avant de déployer un workflow à toute votre équipe, parcourez le processus avec une ligne de test pour vérifier que chaque transition, condition et approbation se comporte comme prévu.

Prochaines étapes

• Explorez les Automatisations pour des règles événementielles « quand ceci se produit, faire cela » qui complètent les transitions de workflow.
• Consultez les Permissions de board pour comprendre comment les rôles de board interagissent avec les conditions de workflow.
• Découvrez les Types de champ pour comprendre quels types de colonne fonctionnent avec les validateurs et les post-fonctions.