Approved manufacturer list control for a PCBA project should separate stewardship of the active list from technical suitability, source approval, quality evidence, conditions of use, and effectivity.
A PCBA approved manufacturer list needs more than one owner. A data steward maintains the active controlled object, sourcing supplies market and traceability evidence, engineering or customer authority approves technical suitability, and quality verifies the evidence required by the project.
At this gate, the first task is to define the term. Some organisations use AML for manufacturers, AVL for vendors or sources, and other teams mix the labels. The project should state whether each row controls manufacturer, exact MPN, distributor, source, site or a combination.
For this check, the EMS supplier may propose an alternate and supply evidence, but that proposal does not become approved unless the buyer’s contract, QMS or delegated authority allows it. The role matrix must be project-specific.
Write the authority model beside the list instead of relying on department names alone. One engineer may approve electrical substitution but not product certification, customer requirements or purchasing sources. Likewise, a quality reviewer may verify traceability without deciding circuit suitability. Row-level roles make those limits visible and reduce the chance that an informal recommendation becomes an unrestricted approval.
Define What Each Approved-List Row Controls
Define what the project’s approved list actually controls. A manufacturer list, approved-part list, and approved-source list may serve different purposes, and local use of AML or AVL can vary. State whether a row identifies the manufacturer, full ordering code, purchasing source, site, configuration, condition, or effectivity. Keep the row linked to the assembly and controlling BOM revision where applicable.
The components management workflow should use that definition consistently. Name the data steward who maintains the record and the separate roles that decide technical suitability or permitted sourcing. An abbreviation alone cannot tell a purchaser what is approved. If existing rows mix several meanings, clarify the scope before using the list to authorise a new part, source, or purchase.
Begin with the project’s definitions. One organization may use an approved manufacturer list to control exact maker and part identities while maintaining supplier approval in a separate system. Another may use different terms. Record the meanings and the relationship between the lists before assigning permissions. A row should identify the part, product context and approval state clearly enough that purchasing cannot mistake an approved supplier for approval of every component that supplier is able to offer.
Assign a data steward for the active list
Assign the steward responsibility for identity, revision state, access, and controlled publication of the list. The steward should be able to trace a proposed row to its request, supporting review, approval, and effective scope. Record corrections without silently replacing the history needed to understand earlier purchasing or production decisions. Keep active and superseded entries distinguishable to ordinary users.
Use the BOM risk report to track unresolved entries, but do not make the steward the default technical approver simply because they edit the file. Define the evidence required before an entry can change state and the route for conflicting instructions. A row should not become approved because it was copied into the current spreadsheet or supplied by a familiar vendor.
The steward should be able to distinguish a proposed edit from an authorized status change. For a new row, retain the request and route it to the required reviewers while keeping its proposed status visible. For an approved edit, record the supporting decision and revision history. When responsibility changes, transfer access and open actions explicitly. Maintaining the list is a data-control responsibility; it does not by itself give the steward authority to decide technical suitability or accept an exception.
Maker identity check: review manufacturer, MPN, site, channel against the active project records. Separate Approved Manufacturer List Control from Technical Approval
Name the authority that decides whether a proposed manufacturer and part are suitable for the defined application. The review should identify the exact ordering code, relevant operating and assembly conditions, supporting sources, and disposition. A recommendation, a completed comparison, and approval for use are distinct states. Record any limitation on configuration, quantity, or build scope.
When changing lifecycle information prompts the review, retain the dated component lifecycle risk review with the decision. That information may explain why an alternate is being considered; it does not establish equivalence or release authority. Ask the technical owner to identify unresolved evidence and the action it prevents. The steward can then publish the actual decision without translating an informal engineering comment into broader permission.
Control task
Accountable role to name
Record to maintain
Escalate when
Define AML and AVL usage
Customer configuration or quality authority
Project definition distinguishing manufacturer approval from supplier approval
The team is using the two lists interchangeably
Maintain approved rows
Designated document steward
Manufacturer, exact MPN, status and revision history
An edit changes approval status without a decision record
Approve technical suitability
Authorized engineering decision owner
Application review and any required verification
Approval is inferred from nominal value or footprint alone
Approve purchasing source
Authorized sourcing and quality roles
Supplier identity and the required source evidence
A purchasable part is being treated as automatically design-approved
Use sourcing to supply market and source evidence
Approved manufacturer list control should keep market and source evidence separate from the engineering decision that permits a named manufacturer and part.
Use sourcing to supply evidence about the proposed purchasing basis: exact item, stated source, offer date, quantity, availability conditions, and applicable project requirements. Keep that evidence tied to its issuer and scope. A distributor listing, earlier quotation, or supplier recommendation may be useful research without proving current allocation or permission to use a substitute.
Route a change to an approved source or part through engineering change control where the project’s process requires it. Sourcing should identify the commercial and material implications it can support, while technical and quality owners make their own decisions. Do not let market availability silently broaden an approved row. If the requested source lacks required evidence, keep the affected purchase decision open and name the missing record.
Sourcing should present evidence the other reviewers can evaluate: exact offered MPN, supplier identity, dated availability basis and any relevant source limitations. Keep market observations separate from commitments the supplier has actually made. If procurement recommends an alternate because the approved item is difficult to obtain, route that proposal through the required technical and quality decisions. A shortage explains why a review is needed; it does not turn the proposed row into an approved production choice.
The procurement evidence view separates data stewardship, sourcing facts, engineering approval, and quality evidence. Apply Quality Evidence to Approved Manufacturer List Control
Define which evidence quality is responsible for checking under the project’s requirements. The task may include reviewing the required source, traceability, inspection, or exception records, but the exact remit should be written rather than inferred from a department name. Identify the object, requirement, reviewer, outcome, and any limitation of the check.
Keep a quality review distinguishable from technical suitability and commercial acceptance. A complete traceability record does not establish electrical compatibility; an engineering approval does not supply a missing purchasing record. Where evidence is insufficient, describe the specific gap and the action it blocks. The approval-list entry should reflect that state so a user cannot mistake a partially reviewed proposal for a fully released source or part.
Quality review should identify the evidence requirements that apply to the project and the proposed change. Record what was examined, the result and any unresolved item, rather than using a generic checked box. If another discipline must decide application suitability, keep that approval open until its authorized owner responds. Where quality has delegated approval authority, state the scope. The final list should show which decision has been completed and should not imply that one review substitutes for every other required approval.
Bound the supplier or EMS proposal role
An EMS provider or supplier may identify candidates, explain procurement constraints, or propose a manufacturing-compatible option. Capture the proposal with its exact manufacturer, ordering code, source, intended application, and supporting evidence. Label its status clearly while the buyer’s required reviews remain open. A proposal should not enter an active approved row through a routine purchasing update.
Agree which decisions the supplier may make under the contract and any documented delegation. If permission covers only nominated options or a limited build, preserve those limits in the list and related instructions. Escalate proposals outside the delegation rather than interpreting silence as consent. The buyer’s process should determine who approves, while the record preserves the supplier’s contribution without overstating it as final authority.
Trace one list row from proposal through specialist review, approval, publication and retirement; note where ownership or authority becomes ambiguous.
Proposed change
Who reviews it
What the steward may do
Release condition
Correct a spelling error
Record owner under the project correction process
Preserve the correction history
Part identity and approval scope remain unchanged
Add a manufacturer or MPN
Engineering and other affected approval roles
Prepare a proposed row without declaring it approved
Required technical decisions are recorded
Change a purchasing source
Sourcing and quality as defined for the project
Update the proposed source reference
Required source approval is complete
Withdraw an approval
Authorized configuration and quality owners
Record effectivity and superseded status
Purchasing and affected material receive the controlled instruction
The proposal interface separates supplier input, review, approval, and list control. Publish Additions, Conditions, and Removals with Effectivity
Supplier-specific notices, such as the TI product-change notification policy , can support source-status review for affected TI parts, but they do not approve an AML row.
Record when an addition, removal, or changed condition becomes usable. Tie effectivity to the project’s meaningful order, lot, work-order, build, or serial references where available. Identify remaining stock and open purchases that still rely on the earlier entry. Removing a row from the latest list does not automatically explain what users should do with material already committed or issued.
Have the responsible owners decide the treatment of that material and communicate the new state to the receiving teams. Preserve superseded entries and their applicable history without leaving them ambiguous in the active release path. When the implementation boundary is uncertain, keep that question visible. The steward publishes the authorised effectivity; they should not invent a material disposition merely to make the list look complete.
A removal needs an implementation instruction as much as an addition does. Identify whether the decision affects only future purchases or also existing stock, open orders and work in process. Record the effective boundary and the responsible disposition owners. Update the active list while preserving the prior state in its history. Then check the purchasing and material views that consume the list so a withdrawn row cannot continue to look approved merely because an old local copy remains in use.
Close exceptions without creating silent approval
Resolve an approved manufacturer list control exception with a named decision, conditions, effective product or lot, expiry, and update to the active list.
Close an exception by resolving the specific issue and recording the authorised outcome. If limited use is allowed, identify the exact item and source, configuration, permitted operation, quantity or build, conditions, and expiry. Keep the exception linked to the affected row without presenting it as unrestricted approval. Later work must be checked against those limits before it proceeds.
When a correction or final approval arrives, retain the prior state and the evidence supporting the transition. Ask another user to retrieve the current permission and identify any remaining exclusion through the normal system. A record that still exposes conflicting active states needs correction even if the approval email is clear. This final readback connects governance decisions to the instructions purchasing and production actually use.
When a conditional row reaches its expiry or approved quantity, the system of record should direct users to the required next decision. Name who checks that event and who can renew, replace or close the permission under the project process. Do not let the steward silently extend a temporary approval by changing a date. The closure record should show the decision, affected scope and active replacement state so another buyer can understand why the row is or is not available.
Cross-function approval: review sourcing, engineering, quality, controller against the active project records. Test Approved Manufacturer List Control Before the Next Gate
Exercise the list with three ordinary transactions: add a manufacturer row, apply a condition and retire a row. The data steward records who proposed each transaction and which specialists supplied technical, sourcing or quality evidence. Another authorised user then locates the active row from the released list and identifies its manufacturer, MPN, applicable assembly and condition. This exposes role gaps that a department name or shared spreadsheet can conceal.
If a working sheet and released list disagree, do not choose between them by timestamp. Preserve the proposal, identify the publishing authority and protect the purchase or build that would consume the disputed row. The steward corrects the active view only after the required approval is present. The history retains the former state so prior builds and traceability records still reflect the permission valid at their release dates.
FAQ
Are an approved manufacturer and approved vendor the same?
Not necessarily. A manufacturer makes the component; a vendor or source sells it. The project should define whether its list controls manufacturer, exact MPN, source, site or several fields.
Can an EMS provider add a manufacturer to the list?
It can propose a change and provide evidence. Final authority depends on the buyer’s contract, QMS and delegation. The approved record should show who decided and the affected scope.
Who should maintain the active list?
A named data steward such as document control or the project owner should maintain revisions and active state. Technical, sourcing, quality and customer owners contribute separate evidence and approvals.
What information should accompany an AML change?
Provide current and proposed manufacturer and MPN, technical comparison, lifecycle and source evidence, validation need, approval owner, effectivity, affected material or builds and open exceptions.
List maintenance also requires a controlled removal path. When a manufacturer, MPN, site or source loses approval, mark the reason, authority, effective date and affected stock or open orders without deleting its history. The active purchasing view must exclude the row while prior build and traceability records keep the identity that was valid at their release date.
Bring the active records to the PCBA approved manufacturer list review
Bring the list definition, active revision, row history, role matrix, supporting technical and sourcing evidence, publication owner and open exceptions. Submit that governance scope through the plain contact page for review.
In the project record, the outcome should make proposal, specialist review, customer authority, active publication and retirement distinct. It does not extend approval to another manufacturer, MPN, source, site or product.
Use the control checklist to separate AML data maintenance, manufacturer evidence, specialist review, customer authority, active publication, and retirement. Confirm each manufacturer and part-number decision against current project requirements before the list is released or changed.
