A controlled, audited, approval-gated path from your CAD system to your ERP. Every phase is documented here using a real carry roller frame assembly as the running example.
The pipeline begins when a CAD file or PDM export is submitted for processing. The file-intake-connector accepts files via API upload, direct Vault pull, or a watched folder on a file server. It assigns a globally unique intake ID to the submission, records the submitting user's identity, and generates a SHA-256 hash of the input file. This hash is the anchor of the audit chain — every subsequent event references the intake ID, and the file hash proves the pipeline operated on exactly this version of the file.
Carry Roller Frame STEP file (carry-roller-frame-rev-b.STEP), submitted by CAD engineer via Vault connector integration. File size: 4.2 MB.
Intake ID assigned: IK-20240615-0042. SHA-256 computed. Submission timestamped. User identity logged from Vault session token.
Intake record written to audit chain. File queued for format detection. Approval Gate G1 notified.
Why it matters: The intake hash is the immutable link between the physical CAD file and everything that happens downstream. If a file is later disputed, the hash proves exactly which version was processed.
Not all CAD files are equal. A STEP file contains different information than a DWG, a DXF, or a Navisworks NWD. The format-router-connector inspects the file header and structure to determine the format definitively — not by extension, which can be renamed — and routes the file to the correct extractor connector. If the file format is not supported or is corrupted, the pipeline stops here with a specific error code rather than proceeding with incomplete data.
File with intake ID IK-20240615-0042. Extension: .STEP. Format detection pending.
File header inspected: confirmed ISO 10303-21 STEP format. Assigned to step-extractor-connector. Routing decision recorded in audit chain.
Format confirmed as STEP AP214. File token passed to step-extractor-connector. Routing record written.
Why it matters: Routing by file content rather than extension prevents silent data loss from misnamed files. A DXF mistakenly named .STEP would be caught here, not halfway through extraction with a confusing error.
The format-specific extractor parses the CAD file and pulls every piece of structured data relevant to the BOM: part numbers, descriptions, revision codes, materials, quantities, unit of measure, mass, finish specifications, and any custom properties defined in the CAD environment. For STEP files, the extractor walks the assembly tree and reconstructs the parent-child hierarchy from the PRODUCT and NEXT_ASSEMBLY_USAGE_OCCURRENCE entities in the STEP schema.
Six extractors are available: step-extractor, iges-extractor, dxf-extractor, dwg-extractor, pdf-extractor (for title block data), and navisworks-extractor. Each is maintained independently and can be versioned and deployed separately from the main pipeline.
STEP AP214 file for carry roller frame. Assembly with multiple sub-assemblies and purchased components.
Assembly tree walked: 32 unique part instances found across 4 assembly levels. Part numbers, descriptions, materials, quantities, and masses extracted for each.
Raw extracted BOM: 32 lines, structured as JSON. Approval Gate G2 notified for engineer review before normalisation proceeds.
Why it matters: Extraction quality determines everything downstream. The extractor operates against the CAD file directly, not a secondary export, which eliminates the risk of stale or incorrectly exported BOM data.
The preview-derivative-service generates thumbnail images and geometry previews for each assembly and component in the BOM. These previews are attached to the audit record and displayed in the approval gate interface so that reviewing engineers can visually verify the geometry matches the part numbers before approving the pipeline run. Previews are generated using the Autodesk Platform Services (APS) derivative API when available, with a fallback to local geometric bounding box rendering for offline environments.
Extracted BOM with 32 components. STEP geometry available for rendering.
APS derivative job submitted. Thumbnails generated for top-level assembly and 8 sub-assembly components. Bounding box previews generated for remaining parts.
Preview assets stored in Azure Blob. Asset URLs attached to intake record and displayed in approval gate UI.
Why it matters: Visual confirmation at the approval gate catches the most common human error: a part number from the wrong assembly being processed. A reviewer can immediately see whether the geometry matches expectations.
Raw extracted data from different CAD environments uses different field names, units, conventions, and formats. The metadata-normalizer maps the raw extraction output to a canonical BOM schema that every downstream connector understands. Field mapping rules are defined in a connector manifest YAML and can be customised per CAD environment and per ERP target without changing the pipeline code.
Normalisation includes unit conversion (kg to lbs, mm to inches if the target ERP requires it), text case standardisation, part number format validation against the organisation's naming convention regex, and deduplication of identical part numbers appearing multiple times in the BOM at the same assembly level.
Raw extracted BOM, 32 lines. Autodesk Vault field names (e.g. _Mass, PartNumber, Engineer Revision).
Field mapping applied. 4 lines with identical part numbers collapsed to 1 with correct total quantity. Mass converted to kg. Descriptions title-cased per naming convention.
Canonical BOM: 29 unique lines (3 duplicate instances consolidated). Ready for validation stage.
Why it matters: Normalisation prevents the same part from being created as multiple ERP items because its description was formatted differently in two CAD files. The canonical schema is the single definition of a BOM line.
The validation stage applies a battery of configurable business rules to the normalised BOM. Rules are defined in a YAML manifest and evaluate completeness, format compliance, ERP readiness, and cross-field consistency. Examples: every BOM line must have a non-empty description; part numbers must match the organisation's regex pattern; any item with a mass greater than 100 kg and no specified lifting provision must be flagged; all revision codes must be single uppercase letters.
Validation failures are categorised as blocking (pipeline cannot proceed until resolved) or advisory (proceed with human acknowledgement). The full validation report, including each rule evaluated and its outcome for each BOM line, is recorded in the audit chain and presented at Approval Gate G5.
Canonical BOM, 29 lines. 47 validation rules configured for this organisation.
All 47 rules evaluated across all 29 lines. 2 advisory warnings: 1 line missing preferred vendor PN; 1 line with description length exceeding 60 chars (D365 field limit). Zero blocking failures.
Validation report generated. 2 advisory items presented at G5 for engineer acknowledgement. Pipeline may proceed with approval.
Why it matters: Catching ERP validation failures before the write attempt saves the cost of partial writes that leave the ERP in an inconsistent state. The validation rules replicate ERP field constraints inside the pipeline.
Before any ERP write is attempted, every BOM line is checked against the live D365 item master. The check determines whether each part number already exists in D365 and, if so, whether the existing record matches the incoming BOM data. Three outcomes are possible: item does not exist (will be created), item exists and matches (no action required), or item exists with differences (will be updated — triggers BOMDiff for that item).
29 validated BOM lines with part numbers. Live D365 connection (read-only at this stage).
D365 item master queried for each part number. Results: 18 existing exact match, 7 new (not in D365), 4 existing with attribute differences.
Write plan: 7 creates, 4 updates (BOMDiff generated for each), 18 no-action. Write plan presented at G6 for review.
Why it matters: Attempting to create an ERP item that already exists with a different description is the most common source of duplicate item proliferation. Checking first makes the intended outcome explicit and reviewable.
The item classifier assigns a type and procurement route to each BOM line in the write plan. Items flagged for creation receive a full classification. Items flagged for update receive a re-classification to confirm the type has not changed (type changes on existing ERP items require additional human confirmation). The carry roller frame example includes fabricated steel components, standard bearings, commercially available idler rollers, and a phantom outer frame assembly used only for geometric reference in the CAD model.
Write plan with 7 creates and 4 updates. All 11 items require classification.
Classification: 3 fabricated (route to workshop), 2 bought-out vendor match (bearing PN confirmed), 1 bought-out RFQ required (idler roller no vendor match), 1 phantom (suppress). 4 updates: all type confirmed unchanged.
Updated write plan: 6 creates (1 phantom suppressed), 4 updates, procurement actions assigned. G7 notified: 1 RFQ item requires procurement manager acknowledgement.
Why it matters: The phantom assembly suppression alone prevents 5–15 phantom ERP items per typical conveyor BOM — items that would appear in reports, affect stock counts, and confuse procurement indefinitely once created.
With all approvals collected (G1 through G8), the writeback connector executes the approved write plan against the live D365 instance. Creates and updates are performed as a transactional batch where the ERP supports it, or as individual operations with rollback tracking where it does not. Each write operation is recorded in the audit chain with the ERP record ID returned by D365, completing the link from CAD file to ERP record.
The writeback connector handles D365-specific field formatting requirements: UoM codes, item group assignments, cost accounting dimensions, and the item type enum values that differ between D365 versions. These mappings are maintained in the connector manifest, not hardcoded.
Approved write plan: 6 creates, 4 updates. All 8 approval gates confirmed. Live D365 write connection active.
6 items created in D365 item master. 4 items updated. Each operation returns D365 Item ID. All operations successful. Total elapsed: 23 seconds.
10 D365 records written. ERP record IDs linked to BOM lines in audit chain. G9 post-write verification triggered.
Why it matters: The writeback connector is the only point where the ERP is modified. All validation, classification, and approval happens before this stage. By the time the write executes, every line has been checked, classified, and signed off.
After the ERP write completes, the audit-seal-connector reads back each created and updated record from D365 and verifies that the written data matches the approved write plan. This catch confirms that the ERP accepted the data exactly as submitted — ERP systems occasionally transform or truncate field values silently on write. Any discrepancies between the written plan and the read-back data are flagged for immediate review before the pipeline is marked complete.
Once verification passes, the pipeline run is sealed: the final audit record is written with the complete event hash chain, the pipeline status is set to COMPLETE, and a summary report is generated for the submitting engineer and all approval gate participants. The audit chain is now closed and immutable.
10 D365 record IDs from writeback. Approved write plan for comparison. Audit chain with all preceding events.
All 10 records read back from D365. Field-by-field comparison against write plan: all match. Chain hash computed over all 47 audit events.
Pipeline status: COMPLETE. Audit chain sealed. Summary report sent to 4 participants. Carry Roller Frame BOM is now in D365, validated, classified, and fully traceable.
Why it matters: The sealed audit chain is the answer to every future question about this BOM: who submitted it, what version of the CAD it came from, who approved each stage, what was written, and whether it arrived in the ERP correctly. No more starting investigations from scratch.
Book a technical demo and we'll walk through all 10 phases using a BOM from your industry. No slides — live pipeline, real data.
Book a DemoOr email demo@verdentic.com