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.

​
How MOA changes the workflow

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

​
A serial-tracked MOA part at a quantity above one

When a made-on-assembly build requirement is for a serial-tracked part at a quantity above one, that quantity is that many separate physical assemblies. ION treats them that way:
  • Each unit is created with its own serial number, and each serial is unique for the part number.
  • Each unit carries its own set of child build requirements, so an install is attributable to the unit that received it.
  • Progress is measured per unit. Over-filling one unit doesn’t cover a unit that’s still empty, so the requirement reads short until every unit meets its own demand.
Each unit is serialized inventory in its own right: you can find it by its serial number, and it can’t be split or merged into other inventory. A run step that still has an unmet requirement on any unit can’t be completed, unless your organization turns on Allow run steps to complete without required install. For more information, see Configure run enforcement.
A run created before per-unit requirements were introduced keeps the shape it started with: one shared set of child requirements across the units. Only new runs get per-unit requirements.

​
Assign an MOA child to a run step

A made-on-assembly child requirement can be assigned to a run step in the same run, like any other build requirement, from the Part Installs (aBOM) dialog. The step must be in Redline. For the steps, see Edit build requirements.

​
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

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