Die Workflow Engine: Contracts → Workflows → Asset Stages
Wie die Plattform einen Contract mit einem Workflow und den Workflow mit den Stages eines Assets verdrahtet, und warum eine Workflow-Änderung nie einen laufenden Contract umschreibt.
Ein ITAD-Workflow ist das Rezept dafür, was zwischen Rampe und Deal mit einem Asset passiert. Annehmen, testen, löschen, graden, fotografieren, listen. Die Reihenfolge zählt; die Schritte unterscheiden sich pro Contract-Typ und pro Gerätekategorie. Die Workflow Engine ist der Teil der Plattform, der dieses Rezept explizit macht, statt es als Flurwissen liegen zu lassen.
Die dreischichtige Verknüpfung
Ein Contract definiert die kommerziellen Bedingungen (Pricing, SLAs, Zertifizierungen). Er trägt einen Workflow, der die operativen Schritte für Assets unter diesem Contract definiert. Der Workflow definiert die Stages, die die Assets durchlaufen, jede mit ihren verpflichtenden und optionalen Actions, Exit Conditions, SLA-Stunden und der Rolle, der sie zugewiesen ist. Der Workflow Standard ITAD läuft zum Beispiel über Collection, Receiving, Diagnostics, Data Erasure, Inspection & Grading, OS Deployment, Valuation & Listing, Shipping und Settlement.
Acht Presets, kein Editor
Die Plattform liefert acht Preset-Workflows: Standard ITAD, Lease Return Processing, Data Destruction Only, Recycle Only, Buyback / Trade-in, Broker / Resale, Refurbishment Workshop und Logistics Only. Unter /settings/core/workflows aktiviert oder deaktiviert Ihr Team sie und wählt einen als Tenant-Default; die Detailseite zeigt jede Stage, ihre Actions, Exit Conditions, SLA und Rolle, die Kategorien, für die sie gilt, die Unternehmen, die sie nutzen, und die aktiven Assets pro Stage. Duplizieren und Bearbeiten werden bewusst nicht angeboten: Ein Workflow ist ein Vertrag zwischen Ihren Operatoren und Ihrer Evidence, und ein halb bearbeiteter ist schlimmer als ein Preset, das alle verstehen.
Welchen Workflow ein Contract bekommt
Beim Anlegen eines Contracts schlägt die Plattform einen Workflow vor und zeigt die Wahl vor dem Speichern. Ist der Tenant-Default aktiviert, gewinnt der Default; sonst entscheidet der Contract-Typ — ITAD-Service zu Standard ITAD, Lease Return zu Lease Return Processing, Remarketing zu Broker / Resale, Recycling zu Recycle Only. Der auf dem Contract gespeicherte Workflow ist ab dann der, der Inbound und angenommene Assets darunter steuert. Den Tenant-Default später zu ändern betrifft nur neue Contracts; ein laufender Contract wechselt nie den Workflow, weil jemand in den Einstellungen einen Schalter umgelegt hat.
Stage-Tracking pro Asset
Jedes Asset hat eine aktuelle Stage und einen Status, und die Pipeline-Ansicht (/core/pipeline) ist der tenantweite Blick darauf, wo die Arbeit pro Workflow und Stage steht. Statusübergänge sind serverseitig begrenzt — ein Asset läuft von received über Diagnostics, Erasure und Grading in Richtung ready for sale, und die Plattform lässt es nicht von Receiving zu ready-for-sale springen, weil es jemand eilig hatte.
Was die Engine weiterreicht
Zwei Übergaben sind heute verdrahtet. Aus einer abgeschlossenen Inbound Order unter einem bepreisten Contract lässt sich ein Entwurf-Settlement erzeugen, sobald ihre Assets terminal sind oder die Stage hinter sich haben, die die Settle-Action trägt; es landet als Entwurf zur Prüfung bei Finance. Und Zum Verkauf listen gibt es sowohl als Workflow-Action als auch als Bulk-Action im Inventory neben „Aufbereitung protokollieren“, sodass eine gegradete Charge über dieselbe Market-Ready-Prüfung in die Verkaufsschicht geht wie ein einzelnes Asset. Keine der beiden passiert still: Beide sind User-Aktionen, beide schreiben Activity.