For IT and whoever owns the ERP

What you are actually evaluating

Not whether the PLM has the features engineering asked for — they will tell you that. You are evaluating three things: whether the integration will corrupt your ERP, whether the isolation story survives your security review, and whether this becomes a system you are asked to babysit.

The three have different answers and different evidence, and none of them are addressed by a feature list. What follows is the evidence for each, including the parts that will not satisfy every reviewer.

The integration: ownership is published, not discovered

The system-of-record matrix is a table with one row per object and four columns: which system masters it, which direction values move, what triggers the movement, and what happens when the two disagree. It is published as a public page per connector, and it is the connector's run-time configuration rather than a document somebody wrote during implementation.

The defaults: item identity, released BOM and change records master in Manufacturing PLM. Cost, on-hand, lead time and the supplier record master in your ERP and read back read-only. MBOM ownership is genuinely contested and is decided per tenant rather than assumed by us.

On conflict, a reconciliation task — never an overwrite. Somebody will edit a published structure in the ERP, usually for a good reason. What you get is a task naming the object, the field, both values and the owning system, in the same work queue as everything else rather than in an integration console nobody opens.

Fields the matrix marks as ERP-mastered render read-only throughout the Manufacturing PLM interface, greyed and labelled, not editable even by an administrator. The interface does not offer an action the next sync will undo.

The isolation: a predicate, not a code review

Multi-tenancy is enforced by a predicate injected into every query by the database client extension, sourced from request-scoped context in async local storage. It is not a check written at the top of each route.

That distinction is the whole argument. A per-route check fails silently at whichever route somebody forgot, and the code looks entirely normal because the bug is an absence — there is nothing for a reviewer to notice. A predicate below the query builder has no per-route surface to forget, and the context is not a parameter precisely because a parameter can be omitted at one call site with nothing failing.

Results, totals, facet counts and pagination all derive from one shared clause. A facet reading fourteen next to an empty result list announces the existence of fourteen objects as effectively as listing them. External supplier sessions narrow a second time, and a direct fetch of an unshared object by identifier fails — there is a test that attempts exactly that.

Connector runs establish the same tenant context a user request does, so the predicate applies to sync jobs too. Background work is where isolation usually leaks, because a nightly job typically holds broad credentials and iterates across tenants.

The operational load: what you will actually be asked

Configuration is not a vendor ticket. Object types, attributes, lifecycles, workflows, numbering and branding are tenant data, changed in a sandbox with the same model as production, diffed, costed against real data and promoted with rollback. Your engineering team changes their own model; you are not the queue.

Identity is SSO and SCIM, so joiners and leavers run through the process you already have rather than through a separate user list somebody forgets to prune. Administrators have no silent bypass — an administrator who needs into a restricted programme grants themselves access and leaves an audit row saying so.

The audit trail is hash-chained: each row commits to its predecessor, so a tampered or deleted entry breaks verification and the break is locatable. Writes arriving without an attributed actor are refused rather than recorded as unknown, which means “who changed this” always has an answer.

Sync history is queryable, retries are bounded and idempotent, and publication is all-or-nothing per release. A failed run leaves nothing, because a half-written structure looks complete to whatever planning run reads it next.

How it meets your ERP

Six connectors on one framework: ViBe ERP natively, plus NetSuite, Dynamics 365, SAP S/4HANA, Epicor Kinetic and Acumatica. Each publishes its own field map alongside the shared ownership matrix, because what differs between them is shape rather than ownership.

Shape matters more than it sounds. NetSuite takes a dated BOM Revision; SAP takes a Change Master with a valid-from and maps plant effectivity natively; Dynamics takes a versioned Production BOM; Epicor takes a Part Revision and respects your engineering workbench approval gate; Acumatica takes a dated revision on the field MRP already reads. None of that is inferred at run time.

Nothing transactional is written. No purchase orders, production orders, goods movements, invoices or ledger entries, in either direction. Manufacturing PLM reads cost and inventory as context and writes engineering definition, and the boundary is the same on every connector page.

Where the boundary is

This is logical isolation on shared infrastructure. No single-tenant deployment, no on-premise, no ITAR segregation — those are out of scope as a permanent architectural decision rather than a roadmap item. If your programme requires any of them, this is the wrong product and you should know now.

Data residency is not yet regionalised either; production data is held in the EU by default with transfers under the standard clauses. Regional pinning is a tracked commitment for the first customer whose contract genuinely requires it, which may or may not be soon enough for you.