Skip to main content
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

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. 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.”

​
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.

​
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.

​
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, 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.

​
What release does

On confirmation, Alforse processes each affected item according to its change type:
  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.
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”.

​
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.