Parts Library
ION allows you to keep track of your parts as well as keep track of how and where you use those parts in your manufacturing program.
Part objects in ION represent abstractions that carry information about a particular part, while the physical parts themselves are part inventory objects. The part objects dictate the mBOM, revision, supplier part number, tracking type, lead time, unit of measure, and other additional attributes about a part that get carried over to your factory. A part is a unique combination of Part Number and Revision.
What is a part, and when should I create a Part?
A part represents a unique combination of parts and processes that can exist as a standalone product in your inventory. We recommend creating a part if it meets the following criteria:
An instance of that part (i.e., part inventory) can be stored in a warehouse.
An instance of that part can be used interchangeably across any serial number of one assembly or be used in multiple types of assemblies (i.e., different part numbers).
Here are example use cases:
A part comes in unpainted (i.e., -001) and can be used for R&D, or can be coated (i.e., -002) and used for flight purposes. This part meets both criteria; it can be stored in a warehouse, and the part can be used for R&D or Flight if coated. In this case, we do recommend the -002 calls out the -001 in the mBOM.
A car engine that is stored in inventory and can be used for any sedan serial number that comes down the line.
Paint that is used for any vehicle, whether it's a sedan or a SUV.
When we DO NOT recommend creating a part:
If every part always gets painted during the manufacturing process, than we don not recommend a unique part number for the unpainted part. If the unpainted part is ordered from a supplier, we recommend using the Outside Processing feature to support this use case!
You need to break up a large procedure into smaller segments to effectively split up the procedure definition into multiple teams and more manageable chunks. Instead of creating unique part numbers for each procedure to represent each state of the assembly, we recommend using Use Case: Implementing Nested Steps.
Design Changes: When to Iterate on Part Numbers, Revisions, and mBOM Versions
There are many ways to iterate on your designs in ION; part number changes, new revisions, or iterating on mBOM versions. This guide is to help propose clarity so you know how to get the most out of the system.
Change the Part Number when the item no longer has the same form, fit, or function as its predecessors, and you need to treat it as a different, non-interchangeable thing in planning, purchasing, inventory, or use.
Effect: New Part Number → starts at a new Revision “A”; has its own mBOM and inventory.
Bump the Part Revision when the item keeps the same form/fit/function (policy: interchangeable), but you need a controlled, traceable change (e.g., hole tolerance, finish, spec update).
Effect: Same Part Number, next Revision (e.g., B → C). Interchangeability can be enforced so you can still kit/install older revs if allowed. Turn on part interchangeability here: manual.firstresonance.io
Create a new mBOM Version when the assembly definition changes (components, quantities, substitutes, reference designators) but the assembly’s Part Number/Revision does not.
Effect: Multiple mBOM versions can exist per Part Revision with statuses and approvals (Draft → In review → Released → Archived). aBOM/Autoplan use the latest Released mBOM version by default. manual.firstresonance.io
Major change: different form/ fit/function
Changes
New Part Number
New connector type; new envelope size; performance class change
Separate inventory & demand; new mBOM lineage
Controlled design tweak (interchangeable)
Same
New Revision
Tightened tolerance; material callout change; finish spec
Optionally allow kitting older revs if policy enabled; can auto-flow into mBOMs via automation
Build definition change only
Same
New mBOM Version
Add/remove child, update qty/substitute, change refdes
aBOM + Autoplan use latest Released version
Revisions and Revision Schemas
ION is intentionally flexible when it comes to part revisions, given that every customer has a different schema. In order to set your revision schema, navigate to the parts organization settings and set the format of the revision schema.
You can set the schema to allow overflow, which defines whether an error should be raised when the max iteration of a revision scheme is reached, or if it should overflow to the next available value. For example, you can determine if Z is the last revision in an alphabetical revision schema, or if it should overflow to AA.
The default boolean will automatically mark all newly created parts with this revision scheme unless overriden.
If no revision or revision schema is given, then the part defaults to Rev A. If a revision schema is given, then the part defaults to the first value of that revision schema.
Create a New Part Revision
A revision can be generated from any part, there are no restrictions requiring the revision to be generated from the current latest revision. For example if our part "ion-13" has existing revisions A and B, then a third revision C can be generated from either existing revision A or B. All information in the new revision is copied over from the old revision unless explicitly overridden in the mutation input. The new revision will be the next valid alphabetic character from the part's latest revision. If the part's latest revision is C, then the new revision will be D. If the part's latest revision is Z, then the new revision will be AA. Returns the newly created part object with the updated revision.
Archiving a Part
When archiving a part, ION will prevent any new inventory of that part from being created. Existing inventory will remain unaffected by archiving a part. This will also remove archived parts from dropdowns (i.e. part selection on a run or purchase order). You may unarchive a part by finding them using this filter on the parts library page.
Last updated
Was this helpful?