#️⃣
Part number
Use the identifier customers, dealers, or internal teams need when ordering or requesting the part.
Practical catalog data guide
How to structure spare parts data for reliable parts lookup
The goal is not to create the largest possible spreadsheet. It is to give every customer-facing diagram, collection, and workflow a dependable route to the correct orderable part.
Start from the customer lookup journey
Separate shared data from diagram-specific context
Build review and maintenance into the structure
Start with the questions a customer needs answered
Before choosing fields or rebuilding a catalog, map the decisions someone makes when they need a replacement part.
A customer or technician normally starts with a machine, assembly, model, or exploded view. They then need to recognize the correct callout, understand which part is currently orderable, and move into a quote, cart, or support process.
Your data structure should support that journey. Internal fields are useful only when they help your team maintain the catalog or help the user identify and obtain the right part.
1. Create one shared record for each orderable part number
Keep reusable commercial and descriptive information separate from the diagram position where the part appears.
Core information to consider
The exact fields depend on your business, but these are common building blocks for customer-facing parts lookup.
📝
Customer-facing name
Use a recognizable name rather than relying only on an internal code or abbreviated source description.
📄
Description
Add the context needed to distinguish similar parts, variants, kits, or applications.
💶
Price and currency
Store explicit prices for the markets and workflows where customer-facing pricing is required.
🌍
Language variants
Maintain translated names and descriptions where the catalog serves multiple regions or audiences.
✅
Availability status
Make it clear whether a part should remain visible and usable in active customer workflows.
2. Keep diagram context as a relationship, not a duplicate part record
A part may appear in many schematics, but each appearance can have its own callout number, quantity, and assembly context.
Avoid recreating the same part record for every exploded view. Instead, maintain the part once and connect it to the relevant number labels and schematics.
This separation lets your team correct a shared name, description, price, or image without repeating the same maintenance across every diagram. At the same time, each schematic can preserve the reference and quantity that belong to that specific assembly.
3. Review number-to-part matches before customers rely on them
Automation can reduce repetitive work, but ambiguity and incomplete source material still require human decisions.
1
Check detected callout numbers
Confirm that number labels are present, readable, and positioned on the correct location in the diagram.
2
Compare callouts with BOM rows
Review whether the reference, part number, quantity, and description line up with the relevant assembly.
3
Resolve missing or ambiguous matches
Link, unlink, or replace the associated part where the source material does not produce a dependable result.
4
Publish only the reviewed result
Treat the customer-facing diagram as an approved catalog output rather than a raw extraction result.
4. Use part groups for repeatable operational decisions
Groups are useful when a set of parts needs the same treatment for pricing, filtering, maintenance, or another catalog workflow.
Manual groups
Select the exact parts that belong together when the business rule depends on a curated list or commercial decision.
Dynamic groups
Define reusable conditions based on supported fields such as part number, text, source, category, status, or price, then preview the matching parts.
Groups should not be used to hide poor source data or to merge records that represent different part numbers. Their value is in applying a clear, repeatable decision to a known set of shared parts.
5. Model replacements as explicit relationships
An old part number should not simply disappear when a newer or preferred part becomes available.
Keep the original part recognizable and connect it to the appropriate replacement. Record whether the relationship is official, aftermarket, or compatible, add useful notes, and identify the preferred option where applicable.
This gives customers and service teams a route forward when they search an older manual or encounter a superseded number.
6. Plan how the data will be maintained after launch
A useful structure is one your team can keep accurate when prices, descriptions, replacements, and product ranges change.
A maintainable operating model usually includes
Controlled imports and updates
Use structured files to create or update part records, while reviewing failures and unexpected source values.
Clear ownership of exceptions
Decide who reviews unmatched callouts, missing part numbers, replacement relationships, and publishing decisions.
Shared records across outputs
Use maintained parts across schematics and collections instead of rebuilding the same catalog information repeatedly.
A practical readiness checklist
You do not need perfect source material to begin, but you should know where review and decisions are required.
✓
Your orderable part numbers are identifiable
The source data includes a stable identifier that can be used to maintain and search each part.
✓
Customer-facing names are understandable
A user can distinguish the part without relying entirely on internal shorthand.
✓
Diagram references can be reviewed
Your team can confirm or correct the relationship between callouts, BOM rows, and parts.
✓
Replacement decisions have an owner
Someone is responsible for confirming supersession and preferred replacement relationships.
✓
Languages and currencies are scoped
You know which markets need localized descriptions, prices, or catalog variants.
✓
Publishing has an approval step
Extracted or imported data is reviewed before it becomes part of the customer experience.
Structuring spare parts data
Common questions
Keep the model practical and aligned with the experience you actually want to publish.
Do we need to clean every source file before starting?+
No. You can begin with existing manuals and structured part lists, provided your team can review exceptions and make clear decisions about the information that becomes customer-facing.
Should similar part numbers be merged into one record?+
Only when they truly represent the same orderable part according to your business system. Similar formatting or descriptions are not enough on their own. PartGrid does not automatically merge fuzzy duplicates.
Can one part appear in multiple schematics?+
Yes. A shared part can be connected to multiple diagrams and callouts while keeping the diagram-specific reference and quantity in the relevant schematic context.
Where do replacements belong in the structure?+
Maintain replacements as explicit relationships between part records. This keeps the old number searchable while giving the user a clear preferred or compatible next option.
What should remain a manual review step?+
Ambiguous callouts, missing part numbers, unexpected import values, replacement decisions, and final publishing approval should remain visible decisions for your team.
Review your current catalog structure with a real manual
Bring an exploded-view manual and a representative parts list. We will map how shared records, diagram matching, groups, replacements, and publishing could work for your customer journey.