Die Workflow Engine: Contracts -> Workflows -> Asset Stages
Wie die Plattform einen Contract mit einem Workflow und den Workflow mit Asset Stages verbindet, und was passiert, wenn eine Stage fertig ist.
Ein ITAD-Workflow ist das Rezept dafür, was mit einem Asset zwischen Dock und Deal passiert. Receive, test, grade, erase, photograph, list. Die Reihenfolge ist wichtig; die Schritte unterscheiden sich nach Contract Type und Device Category. Die Workflow Engine ist der Teil der Plattform, der dieses Rezept explizit macht, statt es als Teamwissen herumliegen zu lassen.
Die dreischichtige Verknüpfung
Ein contract definiert die kommerziellen Bedingungen (pricing, SLAs, certifications). Er verweist auf einen workflow, der die operativen Schritte für Assets unter diesem Contract definiert. Der Workflow definiert die asset stages, die Assets durchlaufen: typischerweise receiving → testing → grading → erasure → ready-for-sale, mit optionalen Verzweigungen (failed-testing → retest, demanufacturing → component-harvest, recycling-bound → recycler-prep).
Stage Tracking pro Asset
Jedes Asset hat eine current stage, eine stage-history und einen next-action prompt. Die pipeline view (/core/pipeline) ist die tenantweite Sicht auf die aktuelle Stage jedes Assets, sortierbar pro Stage. Die Workflow-Definition steuert, welche Übergänge gültig sind — die Plattform lässt ein Asset nicht von receiving zu ready-for-sale springen und testing überspringen.
Stage Completion kann das nächste Artefakt erzeugen
Hier verdient die Engine ihren Platz. Das Abschließen einer Workflow Stage kann automatisch das nächste Artefakt erzeugen: Erasure abschließen kann ein Settlement erzeugen (unter einem lease-return contract mit Chargeback-Regeln), Testing an einem market-bound asset kann eine draft listing erzeugen, Receiving abschließen kann einen inbound-completion report für den Kunden erzeugen. Die Auto-Generation ist explizit (pro Stage im Workflow definiert) und audit-logged.
Workflow-Typen pro Contract Type
Lease-return assets laufen einen anderen Workflow als buyback assets, und diese wieder einen anderen als recycling assets. Die Plattform liefert Default Workflows pro Contract Type, und Tenants können aus /settings/core/workflows clonen und customizen. Die Customization passiert auf Workflow-Ebene (welche Stages, welche Auto-Generations), nicht pro Asset — eine Workflow-Änderung gilt für alle Assets unter Contracts, die diesen Workflow ab jetzt nutzen.