Le workflow engine : contracts → workflows → asset stages

Un workflow ITAD est la recette de ce qui arrive à un asset entre le quai et la transaction. Recevoir, tester, effacer, grader, photographier, lister. L’ordre compte ; les étapes changent selon le type de contrat et la catégorie d’appareil. Le workflow engine est la partie de la plateforme qui rend cette recette explicite au lieu de la laisser dans les habitudes d’équipe.

Le lien en trois couches

Un contract définit les termes commerciaux (pricing, SLAs, certifications). Il porte un workflow qui définit les étapes opérationnelles des assets sous ce contrat. Le workflow définit les stages que les assets traversent, chacune avec ses actions obligatoires et optionnelles, ses conditions de sortie, ses heures de SLA et le rôle auquel elle est assignée. Le workflow Standard ITAD, par exemple, enchaîne Collection, Receiving, Diagnostics, Data Erasure, Inspection & Grading, OS Deployment, Valuation & Listing, Shipping et Settlement.

Huit presets, pas d’éditeur

La plateforme livre huit workflows prédéfinis : Standard ITAD, Lease Return Processing, Data Destruction Only, Recycle Only, Buyback / Trade-in, Broker / Resale, Refurbishment Workshop et Logistics Only. Sous /settings/core/workflows, votre équipe les active ou les désactive et en choisit un comme défaut tenant ; la page de détail montre chaque stage, ses actions, ses conditions de sortie, son SLA et son rôle, les catégories auxquelles elle s’applique, les companies qui l’utilisent et les assets actifs par stage. Dupliquer et modifier ne sont délibérément pas proposés : un workflow est un contrat entre vos opérateurs et vos preuves, et un workflow à moitié modifié est pire qu’un preset que tout le monde comprend.

Quel workflow reçoit un contrat

À la création d’un contrat, la plateforme propose un workflow et montre le choix avant l’enregistrement. Si le défaut tenant est activé, c’est lui qui l’emporte ; sinon, le type de contrat décide — service ITAD vers Standard ITAD, lease return vers Lease Return Processing, remarketing vers Broker / Resale, recyclage vers Recycle Only. Le workflow enregistré sur le contrat est celui qui pilote ensuite les assets inbound et reçus sous ce contrat. Changer le défaut tenant plus tard n’affecte que les nouveaux contrats ; un contrat en cours ne change jamais de workflow parce que quelqu’un a bougé un interrupteur dans Paramètres.

Suivi de stage par asset

Chaque asset a une stage courante et un statut, et la pipeline view (/core/pipeline) est la lecture tenant-wide de l’endroit où se trouve le travail, par workflow et par stage. Les transitions de statut sont contraintes côté serveur — un asset passe de reçu à diagnostics, effacement et grading vers ready for sale, et la plateforme ne le laissera pas sauter de receiving à ready-for-sale parce que quelqu’un était pressé.

Ce que le moteur transmet

Deux passages de relais sont câblés aujourd’hui. Un settlement en brouillon peut être généré depuis un inbound order terminé sous un contrat tarifé, une fois que ses assets sont terminaux ou au-delà de la stage qui porte l’action de règlement ; il atterrit en brouillon pour revue par la finance. Et Mettre en vente existe à la fois comme action de workflow et comme action groupée d’Inventaire, à côté de Journaliser le reconditionnement, si bien qu’un lot gradé rejoint la couche de vente par le même contrôle market-ready qu’un asset seul. Ni l’un ni l’autre ne se produit en silence : ce sont deux actions utilisateur, et toutes deux écrivent dans Activity.