Import is not a one-time job
Most tools treat import as a migration utility that gets used once and then rots. In practice a manufacturer imports something most weeks — a supplier's updated list, a contract manufacturer's structure, a bulk attribute correction — and the tool that handles that badly costs more than the migration did.
What it is, and what it is not
A staged pipeline for bringing structured data in: extract through a named path, map fields to types, validate against the model, deduplicate, and commit as one transaction — with the whole run reversible afterwards.
It is not a CSV upload. The difference is that nothing commits until the last stage, so an import is inspected as a proposal rather than discovered as a result. A tool that writes as it reads is one nobody dares run against production.
It is also not only for migration. The named paths from Arena, Duro, Fusion Manage, OpenBOM and Excel exist for that, and the same pipeline handles the ordinary weekly work — a supplier sending an updated price and lead-time list, a contract manufacturer returning a marked-up structure, a bulk attribute fix after a classification change.
The mechanism: nothing commits until the end
Extract through a path that knows the source's shape, rather than a generic importer treating every system as a spreadsheet. Map each source field to a target type, with unmapped fields reported rather than dropped — the field you have never heard of is reliably the one somebody depends on.
Validate against the model. Errors name rows: not four thousand errors, but row 4,412, part 510-0090, quantity 8 EA in a numeric column with three reference designators listed. That distinction is the difference between an import somebody fixes and one that stalls.
Deduplicate on manufacturer part number then internal number, never on description similarity. A missing match is a task; a wrong match takes referencing structures with it and cannot be cleanly undone.
Commit as one transaction. The run lands completely or nothing does, and it reverses in one action afterwards — which is what makes it safe to rehearse rather than a thing you only dare do once.
The failure it prevents
A supplier sends an updated list: nine hundred lines, new lead times, twelve discontinued parts, three new manufacturer alternates. Somebody imports it on a Friday.
The importer writes as it reads. Four hundred rows in, it hits a row where a lead time arrives as 12-14 weeks in a numeric column and stops. Four hundred rows are now updated, five hundred are not, and there is no record of which — because a partial import is not a state the tool models.
The recovery is a manual reconciliation against a spreadsheet nobody trusts, performed by somebody who now believes imports are dangerous. The defect was not the malformed row; it was writing before validating. A staged pipeline reports that row and commits nothing.
How it meets the rest of the product
Imported objects go through the same domain services as anything else, so an import cannot edit a released revision, skip required attributes its class declares, or create objects without an attributed actor. The import is a caller, not a back door.
Every imported object carries the run that created it in the audit trail, so “where did this part come from” resolves to a run, a file and a person rather than an assumption. That is the question asked most often about data nobody remembers entering.
Validation uses the class model: required attributes, unit conversions, effectivity shapes. An import into a class with a mandatory field fails those rows explicitly rather than creating objects that cannot be released later — which is the quiet failure that produces a tenant full of parts stuck in draft.
Duplicate candidates surfaced during an import feed the same reuse detection the create-part flow uses, so consolidating them afterwards runs through change control with an impact set and a rollback.
How it meets your ERP
Item identity is matched against your live ERP during the import, not afterwards. Manufacturer part number first, internal number second, with anything unmatched surfaced for a person. That ordering is what turns a quarter-long reconciliation project into a finite pre-cutover list.
It matters for ordinary imports too, not just migration. A supplier list containing parts your ERP already holds under its own numbers will otherwise create engineering duplicates of items purchasing has been transacting against for years.
Nothing imported publishes automatically. An import creates or updates objects in Manufacturing PLM; anything that should reach your ERP does so through a change release like every other outbound movement, carrying its effectivity date.
Where the boundary is
It does not import history that was never recorded. If a source held one version field, the distinction between released revisions and in-progress saves was never captured and cannot be reconstructed — you import what exists, and the finer model applies from that point forward.
There is also no scheduled automatic import from a supplier's system. An import is initiated deliberately, because a pipeline that runs unattended against data somebody else controls is a way for an outside party to change your product data without a change process — which is exactly the hole the rest of the product closes.
Facts
| Stages | Extract · map · validate · deduplicate · commit |
| Commits | Only at the last stage — inspected as a proposal |
| Errors | Name rows, never counts |
| Unmapped fields | Reported, never dropped silently |
| Dedupe | MPN then internal number — never description similarity |
| Reversible | The whole run, in one action |
| ERP identity | Matched during the import, not reconciled after |
| Not offered | Unattended scheduled import from a third party |
Frequently asked
Is this only for migration?
No, and treating it that way is why most import tools rot. A manufacturer imports something most weeks — a supplier's updated list, a contract manufacturer's marked-up structure, a bulk attribute fix — and handling that badly costs more over time than the migration ever did.
What happens if a row is malformed?
It is reported by row number with the specific problem, and nothing commits. The common failure is an importer that writes as it reads, stops four hundred rows in, and leaves no record of which rows were updated — because partial state is not something it models.
Can we undo an import?
Yes, the whole run in one action. That is what makes it safe to rehearse rather than something you only dare do once, and rehearsal is the single best predictor of a migration going well — because the decisions change between runs even when the data does not.
How are duplicates handled?
Detected on manufacturer part number then internal number, never on description similarity, and surfaced as candidates rather than merged. A missing match is a task somebody works through; a wrong match takes the referencing structures with it and cannot be cleanly undone.
Does it check required fields?
Yes, against the class model — required attributes, unit conversions, effectivity shapes. Rows failing those are reported explicitly rather than creating objects that cannot be released later, which is the quiet failure producing a tenant full of parts stuck in draft.
Will imported data reach our ERP?
Not automatically. An import creates or updates objects inside Manufacturing PLM, and anything that should cross to your ERP does so through a change release like every other outbound movement, carrying its effectivity date with it. Import and publication are deliberately separate operations.
Can a supplier's system import into ours on a schedule?
No. An import is initiated deliberately, because an unattended pipeline running against data somebody else controls is a way for an outside party to change your product data without passing through a change process — which is precisely the hole everything else here closes.