The Workflow Engine: Contracts → Workflows → Asset Stages

An ITAD workflow is the recipe for what happens to an asset between dock and deal. Receive, test, erase, grade, photograph, list. The order matters; the steps differ per contract type and per device category. The workflow engine is the part of the platform that makes that recipe explicit instead of tribal.

The three-layer linkage

A contract defines the commercial terms (pricing, SLAs, certifications). It carries a workflow that defines the operational steps for assets under that contract. The workflow defines the stages the assets walk through, each with its required and optional actions, exit conditions, SLA hours and the role it is assigned to. The Standard ITAD workflow, for example, runs Collection, Receiving, Diagnostics, Data Erasure, Inspection & Grading, OS Deployment, Valuation & Listing, Shipping and Settlement.

Eight presets, no editor

The platform ships eight preset workflows: Standard ITAD, Lease Return Processing, Data Destruction Only, Recycle Only, Buyback / Trade-in, Broker / Resale, Refurbishment Workshop and Logistics Only. Under /settings/core/workflows your team enables or disables them and picks one as the tenant default; the detail page shows every stage, its actions, exit conditions, SLA and role, the categories it applies to, the companies using it and the active assets per stage. Duplicate and edit are deliberately not offered: a workflow is a contract between your operators and your evidence, and a half-edited one is worse than a preset that everyone understands.

Which workflow a contract gets

When a contract is created, the platform proposes a workflow and shows the choice before saving. If the tenant default is enabled, the default wins; otherwise the contract type decides — ITAD service to Standard ITAD, lease return to Lease Return Processing, remarketing to Broker / Resale, recycling to Recycle Only. The workflow saved on the contract is the one that drives inbound and receiving assets under it from then on. Changing the tenant default later affects new contracts only; a running contract never changes workflow because somebody moved a switch in Settings.

Per-asset stage tracking

Each asset has a current stage and a status, and the pipeline view (/core/pipeline) is the tenant-wide read of where the work sits per workflow and stage. Status transitions are constrained server-side — an asset moves from received through diagnostics, erasure and grading toward ready for sale, and the platform will not let it skip from receiving to ready-for-sale because someone was in a hurry.

What the engine hands off

Two handoffs are wired today. A draft settlement can be generated from a completed inbound order under a priced contract, once its assets are terminal or past the stage that carries the settle action; it lands as a draft for finance to review. And List for Sale exists both as a workflow action and as an Inventory bulk action next to Log refurbishment, so a graded batch goes to the sales layer through the same market-ready check as a single asset. Neither happens silently: both are user actions, both write Activity.