Skip to main content
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. This page covers how MOA changes the workflow, how to configure it, and how it behaves at run time.

​
How MOA changes the workflow

AspectNormal sub-assemblyMOA sub-assembly
Run for the subSeparate run, completes independentlyNo separate run; the sub is built within the parent’s run
Inventory pre-buildSub exists as a standalone PartInventory row before installSub is created during the parent’s build
Operator handoffOne operator finishes the sub, another installs itSame operator builds and installs in one flow
aBOM recordParent’s aBOM references the sub’s existing aBOMSub’s aBOM is created and rolled up into the parent’s aBOM during the parent’s run
SchedulingSub appears on its own scheduleSub 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:
  1. Find the build requirement’s row.
  2. 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:
  1. The MOA build requirement renders inline with the parent’s other build requirements.
  2. 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.
  3. 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.
  4. 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.