Getting product data into your warehouse
Analytics teams want the BOM in the warehouse. The mistake everybody makes is exporting the stored lines, because the warehouse then has a conditional statement and no engine to evaluate it.
What it is, and what it is not
Change-data-capture from Manufacturing PLM into Snowflake, BigQuery or Microsoft Fabric: objects, structures, changes, suppliers and audit records landing in your warehouse on a schedule you set.
It is not a reporting product. Manufacturing PLM has dashboards for the questions engineers ask inside the tool, and it does not attempt to compete with the analytics stack your finance and operations teams already run. The point of egress is that they get the data rather than a second BI tool.
It is also not a replacement for the API. A dashboard refreshed nightly is warehouse work; a screen that needs the current answer calls the API. Confusing the two produces a warehouse queried in a request path, which is slow in a way nobody can fix later.
The rule that decides whether this is useful
A resolved structure is exported as a resolution, not as rows for the warehouse to re-evaluate. That single decision is the difference between an export people can build on and one that quietly produces wrong numbers.
A BOM line carries effectivity ranges, option membership and possibly a floating revision reference. Exported raw, the warehouse holds a conditional statement — and every analyst who touches it will write their own evaluation, differently, in SQL, without the variant rules.
The observable consequence is a cost dashboard that counts both the 120-volt and the 240-volt power supply because nothing told it a unit has one. The numbers are close enough to be believed and wrong enough to matter, and the divergence is invisible until somebody compares against the PLM.
So the exported structure tables are resolutions under stated conditions, with the conditions on every row. An analyst querying them gets the same answer the compare screen gives, because it is the same answer.
The failure it prevents
An analytics team builds a product cost model on warehouse tables extracted from the PLM. It is careful work: joins are correct, the refresh is reliable, and the model is used in quarterly planning for a year.
Then somebody notices a product's modelled cost is four percent above what procurement sees. The cause is that the extract carried stored BOM lines and the model summed them, including lines belonging to a variant the company stopped selling eighteen months ago.
Nobody made a mistake. The extract offered rows, the team used them, and the error was invisible because a four percent difference across a range looks like a rounding disagreement rather than a structural one. Exporting resolutions removes the class of error entirely — there is no unresolved data to build on.
How it meets the rest of the product
Access control is not exported. The warehouse receives what the configured egress identity may see, and that scope is stated rather than assumed — because a warehouse copy with field-level rules stripped is the fastest way to undo the access control work everywhere else.
That means a tenant with restricted programmes must decide deliberately whether the egress identity can see them, and the decision is recorded. Most organisations run one scoped egress for general analytics and exclude anything customer-confidential.
Audit records export too, which is frequently the most valuable table for an operations team: change velocity, approval cycle times, how long reconciliation tasks sit open. Those questions are natural in a warehouse and awkward in a PLM.
Every extract is an attributed run in the audit trail with its own history, so the question of what left and when has the same quality of answer as any other connector run.
How it meets your ERP
The warehouse is where Manufacturing PLM data and ERP data usefully meet, and it is the right place for that join rather than either system. Engineering structure from here, transactions from there, and an analyst who can ask a question neither system can answer alone.
Manufacturing PLM deliberately does not attempt that join itself. Reading cost and stock as context for an engineering decision is one thing; becoming a reporting layer over your ERP is another, and a PLM that drifts into the second competes badly with tools built for it.
ERP-sourced values that Manufacturing PLM caches are exported with their source system and as-of stamp intact, so an analyst can tell a resolution Manufacturing PLM can reproduce from a cached read of somebody else's record — which is a distinction that matters more in a warehouse than anywhere, because provenance is what gets lost first in a join.
Where the boundary is
Egress is one-way. There is no path from the warehouse back into Manufacturing PLM, because a write path with no attributed actor and no change process is the hole the rest of the product closes. Analysis that should change product data goes through the API and change control.
There is also no query federation. Manufacturing PLM does not read from your warehouse to answer questions in the interface, which keeps latency predictable and means a screen never depends on a warehouse being available or a credit balance being sufficient.
Facts
| Targets | Snowflake · BigQuery · Microsoft Fabric |
| Mechanism | Change-data-capture, on a schedule you set |
| Structures | Exported as resolutions, with the conditions on every row |
| Why | Raw lines make every analyst write their own evaluation |
| Access control | Egress identity scope is stated, never assumed |
| Audit records | Exported — often the most valuable table for operations |
| Direction | One-way; no path back into Manufacturing PLM |
| Not offered | Query federation · a second BI tool |
Frequently asked
Why export resolutions rather than BOM lines?
Because a raw line carries effectivity ranges, option membership and possibly a floating revision reference. Exported unresolved, the warehouse holds a conditional statement, and every analyst who touches it writes their own evaluation in SQL, differently, without the variant rules.
What goes wrong with raw lines in practice?
A cost model that counts both the 120-volt and the 240-volt power supply, because nothing told it a unit has one. The numbers land close enough to be believed and wrong enough to matter, and nobody notices until somebody compares against the PLM directly.
Does the warehouse copy respect our permissions?
It receives what the configured egress identity may see, and that scope is stated rather than assumed. A warehouse copy with field-level rules stripped is the fastest available way to undo the access control work done everywhere else in the product.
Can we write back from the warehouse?
No. Egress is one-way, because a write path with no attributed actor and no change process is exactly the hole the rest of the product exists to close. Analysis that should change product data goes through the API and passes through change control.
Do you query our warehouse from the interface?
No. There is no query federation, which keeps latency predictable and means a screen never depends on a warehouse being available or on a credit balance being sufficient. Everything the interface needs is answered from Manufacturing PLM's own data, in its own storage, on its own hardware.
Is this a reporting product?
No. Manufacturing PLM has dashboards for questions engineers ask inside the tool, and it does not compete with the analytics stack your finance and operations teams already run. The point of egress is that they get the data rather than acquiring a second BI tool.
What is the most useful exported table?
Frequently the audit records, for an operations team — change velocity, approval cycle times, how long reconciliation tasks sit open. Those questions are natural to ask in a warehouse and awkward to ask inside a PLM built for a different purpose.