Workflows Editor: The Tenant View of the Engine

The workflow engine (see workflows category) runs on definitions that say which stages exist, what completes them, and what they generate. /settings/core/workflows is the tenant-facing view of those definitions — pick from presets, customize per contract type, or build a new workflow from scratch.

Presets

The platform ships with default workflows per contract type: standard ITAD, lease return, recycling, buyback, donation. The defaults cover the common shape — receiving, testing, grading, erasure, ready-for-sale — with the auto-generations wired (settlement on lease-return completion, listing draft on market-bound completion, etc.). A tenant who never customizes anything still gets the workflows working out of the box.

Customization

Each workflow can be cloned and customized per tenant. A common customization: insert an extra stage between testing and grading for a tenant who runs a separate quality-control review. Another: change the auto-generation rule on receiving completion to also create a client-facing receipt PDF. The customization is per-tenant, in tenant_workflow_preferences, so the platform default stays as the fallback for everyone else.

Stage configuration

For each stage in a custom workflow: entry conditions, work-required, completion criteria, exit artefacts (see workflow-stages-and-artefacts article). The editor surfaces these as form fields rather than code — the operations lead can adjust the workflow without writing a database migration.

The editor

The editor is a structured form. The operations lead can adjust stages, criteria, and generated artefacts without writing code, while the underlying workflow definitions stay consistent across contracts.

Per-contract assignment

A contract picks which workflow it uses from the available set. /core/contracts/[slug] shows the assigned workflow and lets the operator change it (with a confirmation that the change applies to assets entering the contract from now on, not historical assets).