Bulk change against the set somebody approved
Replacing a component across forty structures is the operation people most want automated and most fear. The fear is well founded, and it comes down to one question: does the bulk run touch what the reviewer looked at?
What it is, and what it is not
A change that affects many structures at once — superseding a component everywhere it appears, adjusting a quantity across a family, retiring a duplicate part number in favour of a canonical one.
It is not a find-and-replace over the database. The distinction is that a mass change is a change: it has a reviewed impact set, approvals, effectivity, an atomic release and a rollback, exactly like a change touching one part.
It is also not a background job that runs and reports. A bulk operation that reports afterwards is one nobody can approve, because approving it means agreeing to a set nobody has seen.
The mechanism: the reviewed set is the operated set
The impact set computed at draft time is stored with the change, and the bulk operation consumes that stored set. It does not re-query at execution.
That sounds like an implementation detail and it is the entire safety property. A re-query at execution time returns whatever matches now — which may include structures created since the review, or exclude ones that have since been superseded. The reviewer approved a set of forty; a re-query might operate on forty-three.
Because impact analysis is deterministic — no model in the path — the stored set is evidence rather than a snapshot somebody might have edited. Re-running the query returns the same bytes, so a reviewer can verify afterwards that the operated set was the approved set.
Release is atomic across every affected object. Forty structures either all move or none do; there is no partial state in which some products reference the new component and some do not, which is precisely the state that produces a build with mixed configurations.
The failure it prevents
A component is superseded across a family of products. The engineer runs the bulk replacement, it reports forty-one structures updated, and everybody moves on.
Two of those forty-one were not in the reviewed set. One was a structure created that morning by a different team for a new variant; the other was a service kit that had been deliberately excluded during review because it ships to a customer with a contractual configuration freeze.
Nobody notices for months. The service kit breach surfaces when the customer's incoming inspection rejects a shipment, and the conversation that follows is about a contractual commitment rather than a part. The bulk operation did exactly what it was asked; it was asked at the wrong moment.
How it meets the rest of the product
Impact analysis produces the set by traversing typed relationships over resolved structures, so what is included is scoped correctly — a structure that references the component only in a superseded revision is not swept up.
Reviewers can exclude specific objects during review, and the exclusion travels with the change. That matters more than it sounds: the useful bulk operation is almost never *everything*, and a tool that only offers all-or-nothing gets used to do the all case and then hand-corrected.
The Parts Agent's consolidation proposals become mass changes when accepted, which is why merging duplicates is safe here — the merge runs as a reviewed, approved, atomic, reversible change rather than as an irreversible database operation.
Rollback is the ordinary change rollback. A mass change that turns out to be wrong reverses like any other, rather than needing a second bulk operation to undo the first.
How it meets your ERP
A mass change publishes like any other change: on release, carrying its effectivity date, as a resolved structure per affected product. Forty structures publishing is forty publications, each atomic, each retried independently if a connector call fails.
That is deliberately not one enormous payload. A single transaction spanning forty ERP structures would either succeed entirely or leave the connector's retry logic reasoning about partial state across a system it does not control.
Impact analysis reads ERP context before approval, so the reviewer sees which of the forty affected products carry open purchase orders and stock against the outgoing component. A mass change that strands inventory across five products is a different decision from one that strands none, and the numbers belong on the review screen rather than in a follow-up.
Where the boundary is
It does not operate on released revisions in place. A mass change supersedes — creating new revisions of the affected structures through the ordinary process — because editing forty released revisions in place would invalidate everything that references them without a record.
It also will not run without an approved change. There is no administrative bulk-edit that bypasses the process, and there deliberately is not going to be one: a bulk operation outside change control is the single most damaging thing an administrator can do to a product record, and it is usually done to save an afternoon.
Facts
| Operates on | The stored impact set, never a fresh query |
| Why | A re-query returns what matches now, not what was approved |
| Exclusions | Set during review, and they travel with the change |
| Release | Atomic across every affected object |
| Rollback | The ordinary change rollback — no second bulk run |
| Publication | One per affected product, each retried independently |
| Released revisions | Superseded, never edited in place |
| Not offered | Administrative bulk edit outside change control |
Frequently asked
Does the bulk run touch what the reviewer saw?
Yes — it consumes the impact set stored at draft time rather than re-querying at execution time. A re-query returns whatever happens to match now, which may include structures created since the review, or exclude ones that have since been superseded by another change.
Can we exclude specific structures?
Yes, during review, and the exclusion travels with the change itself. The useful bulk operation is almost never everything — a tool offering only all-or-nothing gets used for the all case and then hand-corrected afterwards, which defeats the entire point of automating it.
What happens if it fails partway?
Nothing commits. Release is atomic across every affected object, so forty structures either all move or none do. A partial state where some products reference the new component and some do not is exactly what produces a build with mixed configurations.
How do we undo a mass change?
The ordinary change rollback, rather than a second bulk operation to reverse the first. That matters because an undo implemented as another bulk run has all the same risks as the original, applied by somebody who is now under time pressure.
Does it edit released revisions?
No, it supersedes them — creating new revisions of every affected structure through the normal change process. Editing forty released revisions in place would silently invalidate everything referencing them, leaving no record that the meaning of those references had changed at all.
Is there an admin bulk-edit that skips approval?
No, and there will not be. A bulk operation outside change control is the single most damaging thing an administrator can do to a product record, and it is almost always done to save an afternoon rather than for any structural reason.
What does the reviewer see about stock?
Which of the affected products carry open purchase orders and inventory against the outgoing component, read from your ERP. A mass change stranding stock across five products is a different decision from one stranding none, and that belongs on the review screen.