A library update can change more than a symbol drawing. Parameters used by the BOM, procurement system, or assembly documentation may also be replaced. Review those fields deliberately so that a graphical correction does not silently change the identity of the part being purchased.
Altium’s library update documentation describes comparison and control of parameter changes. Use that field-level evidence to distinguish intended updates from instance-specific information that should remain.
Define parameter ownership
Identify which fields are maintained by the library and which are intentionally specific to the placed design instance. A manufacturer part number may be controlled centrally, while a test note or local function description may belong to the project. Establish the policy before selecting a blanket overwrite or preserve option.
Review empty values as carefully as populated ones. An empty incoming field may mean that information was removed intentionally, is unavailable, or is not maintained by that source. Do not let a missing database value erase a required release field without investigation.
Compare the proposed field changes
| Parameter type | Review |
|---|---|
| Purchasing identity | Does the change select a different physical component? |
| Electrical value | Does it alter circuit intent or only presentation? |
| Assembly instruction | Is a project-specific requirement being overwritten? |
| Documentation link | Does the reference still describe the selected part? |
Check parameter names and aliases used by output templates. Keeping the correct value in one field does not help if the BOM exporter reads another. Trace important fields through the actual generated output to verify their effect.
Apply a controlled update
- Save a recoverable design revision.
- Review proposed changes for representative component classes.
- Accept or preserve fields according to their ownership.
- Check every affected instance and variant.
- Regenerate the BOM and other parameter-dependent outputs.
A sample review can reveal the update mechanism, but it does not justify ignoring unusual instances. Search for locally modified fields, alternate variants, and components with incomplete source records. These are the places where a uniform update policy is most likely to have unintended consequences.
Compare the before-and-after BOM by manufacturer identity, quantity, value, and reference membership. A symbol update that was intended to be graphical should not produce unexplained purchasing changes. If a purchasing change is intentional, document it as an engineering decision rather than an incidental library refresh.
Keep the accepted field changes with the design history. That record helps the next engineer distinguish a deliberate local exception from an obsolete value that survived by accident, making future library maintenance more predictable.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist