Made on assembly (MOA) - ION Manual

Made on Assembly (MOA)

Made on Assembly (MOA) is a flag on a build requirement that marks a child part as constructed directly onto the parent during the parent’s run, rather than as its own separate run. See Bills of materials overview for how the flag sits on the line.

How MOA changes the workflow

Aspect	Normal sub-assembly	MOA sub-assembly
Run for the sub	Separate run, completes independently	No separate run; the sub is built within the parent’s run
Inventory pre-build	Sub exists as a standalone `PartInventory` row before install	Sub is created during the parent’s build
Operator handoff	One operator finishes the sub, another installs it	Same operator builds and installs in one flow
aBOM record	Parent’s aBOM references the sub’s existing aBOM	Sub’s aBOM is created and rolled up into the parent’s aBOM during the parent’s run
Scheduling	Sub appears on its own schedule	Sub doesn’t appear in scheduling; its work lives within the parent’s run

Configuring MOA on a build requirement

From the mBOM card on the part page, with the version in Draft:

Find the build requirement’s row.
Select the Made on Assembly checkbox in that row. The change saves automatically.

The build requirement now executes via the MOA flow at run time.

You can also flag a part as MOA when adding it to an aBOM: turn on the Add as MOA switch before selecting the part in Edit Mode. See Edit build requirements.

How operators install MOA build requirements

During the parent’s run:

The MOA build requirement renders inline with the parent’s other build requirements.
Instead of scanning an existing sub, the operator gets a build flow that walks through the sub’s own procedure, or a sub-sequence inside the parent’s procedure.
As the operator completes the MOA build steps, ION does the following:
- Creates a new PartInventory for the sub, with a serial or lot depending on the sub part’s tracking type.
- Creates the sub’s aBOM as a child of the parent’s aBOM.
- Records installations against the sub’s build requirements as the operator works.
When the MOA sequence is complete, the sub is installed into the parent in a single atomic act: the new sub-assembly is created and installed at the same time.

MOA and traceability

MOA preserves full traceability in both directions:

Top-down: the parent’s aBOM leads to the MOA sub’s aBOM, then to the leaf installations. This is the same recursive tree as a normal sub-assembly.
Bottom-up: a leaf part inventory, such as a fastener, installed in an MOA sub still has a parentPartInventory chain that walks up through the MOA sub to the top-level parent.

The only difference is when the work happened and which operator did it, not what the data records.

MOA and Autoplan

In Autoplan, MOA components surface as Placeholder items in the plan. Placeholders represent the hierarchy of the BOM but can’t be converted into runs or purchases directly. The parent’s run produces them as a side effect of the parent build. Treat them as informational rows in plan output, not as actionable demand.

MOA and run batches

When the parent is part of a run batch, MOA build requirements:

Render once per batched run, one MOA build per parent unit.
Don’t propagate as redlines across siblings the way step-level changes do. Each MOA build is its own piece of work even within a batch.
Still inherit the batch’s procedure version and shared-step sign-off behavior for any non-MOA steps.

If a sub-assembly might eventually be batched separately or stocked, build it standalone. Switching from MOA to standalone after the fact reorganizes your routing.

When sub-assemblies are MOA, you don’t need to kit them separately ahead of the parent build. The components flow into the parent’s kit.

A parent run with several deep MOA sub-assemblies can become a large run for one operator. If the work splits naturally between operators, separate runs can be cleaner even if the sub doesn’t get stocked.

Troubleshooting

A sub-assembly's installs are missing after the run

An MOA sub-assembly’s inventory, its aBOM, and its installations are created only as the operator completes the MOA build flow during the parent’s run. Cause: The MOA build flow wasn’t completed. The sub exists only once its build steps are done. Fix: Complete the remaining MOA build steps on the parent’s run. Cause: Made on Assembly was turned on after the run was created. A run builds against the mBOM version it was created from, so the line runs as a normal sub-assembly that expects an existing sub to install. Fix: Set Made on Assembly on the mBOM before you create the run. Changing it on an in-progress run doesn’t convert installs that already exist.

A made-on-assembly part has no manual install option

Cause: MOA sub-assemblies are created and installed by the parent’s build flow, not through a manual install, so no manual install control appears for them. Fix: Complete the MOA build flow on the parent’s run to create and install the sub.