Centre d’aide/Workflows & automatisation/Stages, substages et ce que "done" veut dire
02Workflows & automatisation3 min de lecture

Stages, substages et ce que "done" veut dire

Comment une stage est définie, ce qui la marque complète, et quels artefacts elle produit.

Une stage dans un workflow n’est pas une description libre. C’est une définition structurée : entry conditions, work-required, completion criteria et exit artefacts. Cette structure rend le moteur déterministe.

Entry conditions

Ce qui doit être vrai avant qu’un asset puisse entrer dans la stage. Pour “testing” : l’asset est dans une warehouse zone de type “processing,” receiving est complet, la device category a une test checklist définie. La plateforme refuse la transition d’entrée si les conditions échouent ; elle affiche la raison précise.

Work-required

L’action qui doit se produire pendant la stage. Pour testing : compléter la test checklist pour la catégorie de l’asset. Pour grading : assigner les quatre sub-grades plus l’overall. Pour erasure : terminer le run de l’erasure tool et importer le rapport. L’action apparaît comme next-action prompt sur le détail asset et dans la queue de l’opérateur.

Completion criteria

Ce qui marque la stage comme terminée. Pour testing : chaque defect-zone requise est cochée, les grades fonctionnel et batterie sont renseignés. La plateforme n’accepte pas un toggle “complete” si les critères ne sont pas remplis ; tenter d’avancer un asset sous-testé affiche l’écart.

Exit artefacts

Ce qui est généré quand la stage se termine. Pour erasure : un certificat d’effacement par disque, un statut D0 sur l’asset, une audit row. Pour grading : une audit row enregistrant les grades et la version des critères, un changement de statut vers “graded.” Certains artefacts sont des documents (PDFs) ; d’autres sont des changements d’état ; d’autres encore sont des créations d’entités downstream (settlement rows, listings, etc.).

Manual override

Un opérateur avec le bon rôle peut avancer manuellement un asset au-delà d’une stage, avec une raison enregistrée. Utilisé pour les cas limites (asset arrivé déjà testé par le client, stage non applicable). L’override est journalisé ; l’audit trail enregistre que la stage a été complétée manuellement plutôt que parcourue normalement.