Connected information, without another system to reconcile.
“Can you connect this new tool?” sounds like an integration request. Often it is an unresolved ownership problem, and IT inherits the job of making mismatched product data behave like a reliable process.
* Illustrative model, not guaranteed savings. See assumptions.
Define the data boundary before connecting
- Tenant isolation: customer workspaces are isolated.
- Restricted supplier access: supplier access is limited to authorised information.
- AI boundaries: controls govern AI providers and processing regions.
Agree data ownership, public DPP fields, support access, retention and deletion during the security review.
Fit your existing Microsoft and AWS environment
Keep your ERP and PIM authoritative. Scope Dynamics 365 or other systems through documented APIs and agreed field mappings. Microsoft Entra ID SSO is ready to integrate; configure and validate it with your IT team. Agree roles and audit requirements. For AWS workflows, agree API access, credentials and network requirements. Connector availability and setup effort are confirmed during scoping.
Implementation: immediate start to 4 weeks
Start fresh
Request information from suppliers immediately. No existing data to migrate.
Bring existing data
Allow up to 4 weeks for files, ERP or PIM data: mapping, cleanup, validation and testing. Timing depends on complexity, data quality and agreed scope.
The ERP contains one product identifier. PLM holds a different component structure. Supplier documents use names rather than IDs. A spreadsheet bridges the gaps until somebody changes it.
A shared record needs more than synchronisation
Moving data between systems does not resolve disagreements about what the data means. Which system owns the approved specification? Who can change a supplier answer? When should a revised value be returned to another system? What happens when two updates conflict?
The W3C’s provenance model distinguishes the data, the activities that produced it and the people or systems involved. That is a useful principle for product-data governance: an answer becomes more useful when its origin and handling can be understood.
Source: W3C: PROV overview
Keystone’s implementation should make those responsibilities explicit.
Connect the collection work to your existing stack
Keystone can connect to ERP and PLM through APIs. Begin by agreeing the records, identifiers and fields involved. The design BOM might remain authoritative in PLM; Keystone can organise supplier collection against that structure, and reviewed information can then be shared or returned through the agreed interfaces. The aim is to reduce unmanaged copies while respecting the systems that already serve the business.
Design the exception before the happy path
A useful integration review includes the difficult cases:
- A supplier uses an unfamiliar component name.
- A product arrives without the expected identifier.
- A new BOM revision changes a material quantity.
- A target system rejects an update.
- A document is replaced after another team has used it.
Agree how each exception is recognised, who resolves it and how the record is reconciled afterwards. A successful demonstration should show recovery as well as data movement.
Start with a flow you can operate
Choose one product family and a small set of fields. Document ownership, access, update direction and error handling. Test the connection with representative records. Then hand it over with clear operational responsibilities.