Tâches refusées et entonnoir des étapes

Le résultat declined

Une tâche refusée lors d'une approbation se termine avec le résultat declined (refusée). Cela couvre deux cas :

• une action d'approbation de la tâche est rejetée (son statut passe à failed) ;
• une transition d'étape soumise à approbation est rejetée pour la tâche.

declined est un résultat terminal, comme completed. Une tâche refusée :

• s'affiche comme declined dans la vue liste, le panneau de tâche et le rail de l'assistant ;
• ne compte plus comme travail ouvert. Elle quitte Needs me, la liste de travail, les notifications de rappel et de retard, ainsi que le balayage d'escalade SLA ;
• n'est jamais signalée en retard.

Le résultat est calculé au moment où la tâche est lue, à partir du journal d'activité du processus. Rien de nouveau n'est stocké : les processus déjà exécutés affichent donc correctement leurs refus, sans migration. Le status stocké de la tâche ne change pas (en général active). Les consommateurs de l'API doivent lire le nouveau champ outcome à la place.

Ce qui lève un refus

Un refus reste en place jusqu'à ce qu'un événement survienne sur la tâche après lui.

Une action d'approbation rejetée est levée lorsque :

• la tâche est déplacée vers une autre étape ;
• l'approbation est soumise à nouveau, ou décidée à nouveau avec un statut autre que rejeté ;
• l'étape est rouverte.

Une transition refusée est levée par chacun de ces événements, ainsi que lorsque la tâche est de nouveau soumise à approbation, lorsque la transition est approuvée ou lorsque la tâche est terminée.

outcome figure dans :

• GET /api/process-flows/{id} (chaque entrée de tasks)
• GET /api/process-flows/{id}/tasks/{taskId}

Un processus qui se termine refusé

Lorsqu'un refus représente tout le travail qu'il reste à un processus, celui-ci se clôt de lui-même avec le résultat declined. Personne n'a besoin de l'annuler ni d'appuyer sur Terminer.

Un processus se clôt comme refusé lorsque :

• au moins une de ses tâches est refusée ;
• aucune autre tâche ne peut encore être traitée : aucune n'est active ni en attente d'une approbation de transition ;
• aucune tâche verrouillée n'attend une heure de déverrouillage planifiée.

Les tâches verrouillées derrière le refus ne maintiennent pas le processus ouvert. Cela couvre une tâche d'une étape ultérieure que le refus empêche de démarrer, et une tâche qui dépend de la tâche refusée. Le processus s'arrête là où le refus l'a arrêté.

Un processus qui a encore d'autre travail reste ouvert jusqu'à ce que ce travail soit terminé. Dès que la dernière tâche est terminée, le processus se clôt comme refusé. Terminer fait de même : il saute les actions facultatives restantes, puis clôt le processus comme refusé. Une tâche refusée ne bloque jamais Terminer.

Le status stocké du processus clos est completed, la même valeur que pour un processus allé jusqu'au bout. Le résultat du processus distingue les deux :

La carte du tableau de bord et l'en-tête de la page du processus affichent Refusé, et la carte de clôture de l'assistant indique que le processus a été clos comme refusé. Le processus apparaît sous l'onglet Completed, car cet onglet liste tous les processus clos.

Le résultat est renvoyé par :

• GET /api/process-flows (le champ outcome de chaque processus ; ajoutez ?limit=N, de 1 à 500, pour ne recevoir que les N processus les plus récents)
• GET /api/process-flows/{id} (data.outcome)
• POST /api/process-flows/{id}/finish (data.outcome)
• l'entonnoir des étapes (flows, voir ci-dessous)

Revenir sur un refus après la clôture

Un processus clos comme refusé peut reprendre. Si quelqu'un décide à nouveau l'approbation refusée, ou rouvre une étape, le processus repasse à in_progress et le travail débloqué continue. Si cette décision était la dernière chose dont le processus avait besoin, il enregistre plutôt un résultat completed normal.

Le processus se clôt, ou reprend, dans le cadre de la décision. Si cette étape échoue, la décision reste acquise, et un passage de maintenance horaire clôt ou rouvre le processus plus tard. Dans ce cas, un processus peut rester in_progress jusqu'à environ 70 minutes après le refus de sa dernière tâche.

L'entonnoir des étapes

L'entonnoir montre comment les instances d'un modèle traversent ses étapes sur une période.

Ses comptes par étape sont des passages de tâches, pas des instances. Un passage est le séjour d'une tâche dans une étape, depuis le moment où la tâche peut y être traitée jusqu'à ce qu'elle la quitte. Une instance dont trois tâches traversent une étape ajoute trois passages à cette étape, et une tâche renvoyée vers une étape qu'elle avait déjà quittée y commence un nouveau passage. Le champ flows, décrit plus bas, compte des instances entières.

Pour chaque étape, l'entonnoir indique :

Les étapes sont identifiées par leur slug (key), ce qui aligne une même étape d'une version du modèle à l'autre.

Dans le tableau de bord

Ouvrez Process Flows et choisissez l'onglet Entonnoir. Choisissez un modèle pour voir les 90 derniers jours. Les jours sont des jours calendaires UTC pour tous les utilisateurs, quel que soit leur fuseau horaire, et le panneau affiche les dates couvertes avec la mention « UTC ». Au-dessus du tableau, une ligne indique comment les processus comptés se sont terminés, y compris combien ont été clos comme refusés. Chaque ligne montre où sont allés les passages de l'étape : avancés, refusés, renvoyés, retirés ou encore ouverts. Ces cinq nombres font le total des Entrées, et la conversion se calcule à partir des quatre premiers.

Via l'API

curl "https://<host>/api/process-flows/stage-funnel?environmentId=$ENV_ID&templateId=$TEMPLATE_ID" \
  -H "x-api-key: $SCRYDON_API_KEY"

La réponse est { "data": { templateId, window, instanceCount, truncated, flows, stages } }. flows répartit les instances comptées par résultat de processus : { open, completed, declined, cancelled }. Sa somme est égale à instanceCount. Une requête compte au plus les 500 instances les plus récentes. S'il y en a davantage, truncated vaut true.

L'appelant doit avoir l'accès en lecture aux processus de l'environnement. Une clé d'API convient : elle est liée à son propre espace de travail et doit appartenir à un utilisateur. Un appelant sans utilisateur derrière lui reçoit un refus 401.

Recette : alerter quand une étape stagne

Aucun bloc dédié n'est nécessaire. L'entonnoir est une API ordinaire, donc un workflow planifié peut le surveiller :

1. Ajoutez un déclencheur Schedule, par exemple chaque lundi à 08:00.
2. Ajoutez un bloc API qui appelle GET /api/process-flows/stage-funnel avec un en-tête x-api-key. Conservez la clé comme secret.
3. Ajoutez un bloc Condition sur l'étape qui vous intéresse. stages suit l'ordre des étapes : stages.0 est la première étape. Par exemple :
   javascript

   <api.data.data.stages.0.conversionRate> !== null && <api.data.data.stages.0.conversionRate> < 0.3

   Référencez le seul nombre que vous comparez, pas la réponse entière. Un bloc Condition insère chaque référence dans l'expression sous forme de texte, et une expression compte au plus 2 000 caractères. <api.data> insérerait tout l'entonnoir, toutes les étapes comprises, et la condition échoue pour tout modèle de trois étapes ou plus.
4. Dans la branche vraie, envoyez la notification avec le bloc de messagerie que vous utilisez déjà (e-mail, Slack, Teams).