> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Lifecycle & release > The five change-notice stages, the Implementation lock and Reopen, the impact panel, the diff review, and what release does at Done. A change notice advances one stage at a time; its stages are the release workflow. **Reopen** from **Implementation** returns it to **Engineering Complete**. **Cancel** closes a notice from any open stage, and **Reopen** from **Cancelled** returns it to **Draft**. ## The stages
**Draft** The change notice is being written. Pick affected items, set change types, and edit each draft method. No notification is sent.
**Start** Work is underway. Advancing to Start notifies the assignee and every action-task assignee.
**Engineering Complete** The design edits are finished and ready for implementation review. Silent, no notification.
**Implementation** The release stage. The engineering content freezes here, and the **"Release"** action becomes available; it reviews every affected item's diff and applies the change. Advancing here notifies.
**Done** Released and locked. The change notice becomes a read-only historical record; notifies on entry.
**Cancelled** The off-ramp. The header's **"Cancel"** action closes the change notice from any open stage without releasing anything. Locked like **"Done"**, but reversible: **"Reopen"** returns it to **"Draft"**.
The **"Start"**, **"Implementation"**, and **"Done"** transitions each notify the people on the change notice: the assignee, plus everyone assigned an action task. Whoever made the transition isn't notified of their own action, and a change notice with no assignee and no assigned tasks advances silently. **"Engineering Complete"** is silent for everyone. Once a change notice reaches **"Done"** it is locked — every editor is read-only. **"Cancelled"** is locked too, but not lost: cancelling keeps every affected item's draft, and **"Reopen"** takes the change notice back to **"Draft"** to pick up where it left off. Only **"Done"** is permanent. Deleting a change notice is the destructive path — that discards each affected item's draft and any new items the change notice minted, so nothing is orphaned. ## Implementation freezes the engineering content At **Implementation**, engineering content becomes read-only while workflow fields remain editable for rollout coordination. | Locked at Implementation (engineering) | Still editable at Implementation (workflow) | | - | - | | Adding or removing affected items | Action tasks — add, complete, skip, reorder, delete | | Changing an affected item's change type | Assignee | | The staged **Bill of Material** and **Bill of Process** drafts | Due date | | The cutover config (supersession mode, discontinuation date, successor effectivity date) | Priority | | **Reason for Change** and **Description of Change** | Category | The lock is enforced on the server, not just greyed out in the UI. If a stale tab tries to write a frozen field you get *"This change notice is being implemented, so its changes are locked. Reopen it to make changes."* NOTE **Reviewing still works while frozen.** Freezing only blocks writes. The **Changes** rollup, each affected item's diff, and the impact panel all stay visible at Implementation — you can read the whole change, you just can't edit it. ## Reopen To change engineering content during Implementation, select **Reopen** from the **⋮** menu. The notice returns to **Engineering Complete**, preserving drafts, diffs, and tasks while unlocking affected items, cutover configuration, and narrative fields. A Cancelled notice uses the same action to return to **Draft**. HEADS UP **Done is terminal — there is no reopen from Done.** Reopen exists only at **"Implementation"** (before release) and at **"Cancelled"** (nothing was released). Releasing to **"Done"** has already activated the new method versions, revealed the new items, and written the supersessions that downstream MRP and Get Method are now acting on. Un-doing that would mean retracting live planning decisions, so Alforse doesn't offer it. To change the same parts again, raise a new change notice — the released methods and items are its starting point. ## The impact panel Alongside the affected items, a change notice shows an **Impact** panel: a where-used tree for each affected item across jobs, job materials, method materials, purchase orders, receipts, quotes, issues, maintenance, and assembly instructions. NOTE **Impact is informational — it never blocks release.** The panel is there so you can see what a change touches before you commit, not to gate you. Nothing in it stops a release; the copy says as much: *"Where the affected items are used across the system. Informational — nothing here blocks releasing."* ## Review the changes, then release The overview's **Changes** card shows a read-only diff for every affected item during authoring. The release dialog uses the same view. Items without edits display *"No changes yet."* Release itself lives on the change notice at **"Implementation"**. The **"Release change notice"** dialog lays out that same per-item diff one more time before you commit — *"Review each item's changes, then confirm — releasing can't be undone."* Each item's diff compares its edited draft against the method it was snapshotted from, across four sections: * **Bill of Materials** — added, removed, and modified BoM lines, field by field. * **Bill of Process** — added, removed, and modified operations and their steps, parameters, and tools. * **Properties** — changed item fields (name, description, unit of measure, tracking type, replenishment system, and the rest), one row per changed column. * **Supplier Parts** — for a purchased Revision, Replacement Part, or New Part, the [suppliers on the line](/docs/reference/change-orders/change-types.md#supplier-parts-on-a-purchased-line), with their part number, unit price, min order qty, order multiple, conversion factor, and purchasing unit. A Revision starts with its source revision's suppliers, so only the ones you added, changed, or removed show here. A Replacement Part or New Part starts with none, so every supplier you add shows as an addition. NOTE **The diff is exact because the draft is real.** There's no shadow copy of your edits to drift out of sync. You edited an actual draft method, so the diff is simply that draft compared against the live one it came from. What you review is exactly what releases. ## What release does On confirmation, Alforse processes each affected item according to its [change type](/docs/reference/change-orders/change-types.md): 1. **Activates the draft method** — it becomes the new **Active** version and the prior Active version is **Archived** (kept as history, never deleted). 2. **Reveals the new item** — for a Revision, Replacement Part, or New Part, the newly created item is switched live and stamped with the change notice id. A Version has no new item. 3. **Writes the supersession** — for a Revision or Replacement Part only, from the old item to the new one, using that affected item's cutover settings. A New Part has no predecessor, so it supersedes nothing. See [Supersession & cutover](/docs/reference/change-orders/supersession.md). New Part items are released first, so a parent assembly whose draft BoM references a consolidated new part finds it already active. When every affected item is processed, the change notice flips to **"Done"**. NOTE **Release is idempotent, not one big transaction.** Each affected item is marked done the moment its draft's change-notice id is cleared, so a re-run skips items already released and resumes at the first unreleased one. The final flip to **"Done"** is a compare-and-swap on the **"Implementation"** status, so two people releasing at once can't double-apply. ## Parallel change notices on the same part Two change notices can revise the same part at once. Each drafts its own method version, and Alforse steps around version collisions so they don't clobber each other. Whichever releases second activates on top of the first, and the earlier version is archived as history rather than overwritten — so no work is lost. There's no merge-conflict step to resolve. ## Related **Supersession & cutover** How a released revision phases over downstream. [Open](/docs/reference/change-orders/supersession.md) **Create a change notice** Start a change notice and pick the affected items. [Open](/docs/reference/change-orders/creating.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.