# Slice 7 (deferred) — a module with workflow

> **Deferred — needs a deployment with deployed BPMN AND the gate
> re-enabled.** Empirically confirmed against the dev DB:
> `act_re_procdef = 0`, `act_ru_task = 0`, `act_hi_procinst = 0`,
> `biz_flow = 0`, `biz_todo_item = 0`, `gdsmoduleflow = 0`, and
> `gdsmodule WHERE bCheck = 1` returns 0 rows. On top of the
> empty-tables state, the dispatch path itself is hard-disabled by
> `ConstantUtils.bCheckflowCheck = false`
> ([Activiti integration](../reference/maintainer/activiti.md)).
> So the slice cannot be exercised against this codebase — the
> [Activiti integration](../reference/maintainer/activiti.md) page
> already documents the code-derived hypothesis.

> **STUB. DEFERRED.** Activiti is wired into the codebase (`xlyFlow` module,
> `act_*` schema, two Activiti versions in `xlyPersist`/`xlyFlow`), but
> the workflow tables (`act_re_procdef`, `act_ru_task`, `act_hi_procinst`,
> `biz_flow`, `biz_todo_item`, `gdsmoduleflow`, `sysflowsendtointerface`)
> populate only in deployments that actually run an approval flow — and
> exercising the slice end-to-end needs such a deployment.
>
> Originally this was Slice 2; the slot was reassigned to
> [multi-tenancy](02-multi-tenancy.md), which is observable everywhere.
> This slice will be filled when a deployment with active flows is
> available, or when we choose to document Activiti as a code-derived
> hypothesis only.
>
> Outline (when ready):
>
> 1. A module with an approval/review step (e.g., quotation → review →
>    sales order).
> 2. The Activiti tables: `act_re_*` (definitions), `act_ru_*` (running),
>    `act_hi_*` (history); the version skew (5.17 in `xlyPersist`, 6.0 in
>    `xlyFlow`).
> 3. xly's wrapper layer: `biz_flow`, `biz_todo_*`, `gdsmoduleflow`,
>    `CheckFlowController`.
> 4. The end-to-end trace from "click submit" → process instance start →
>    task assignment → approver action → process complete.
