Manufacturing CRM with Dual-Write F&O Integration

Tech Stack

The Problem

The client's sales team ran the entire quote-to-cash process outside of any system of record — Excel sheets, email threads, and tribal knowledge. Their F&O platform handled finance, inventory, and production but had no sales layer. A design team had produced a detailed Canva prototype mapping the desired flow (lead intake, qualification, opportunity, quote, order), but that prototype was a click-through mockup, not an implementation. The business needed: a production CRM reflecting the Canva flow exactly, master data staying in sync with F&O (customers, products, pricing), and handoff to F&O when a quote converted to a confirmed order.

Reverse-Engineering the Canva Prototype

Started by reading every screen in the Canva file and extracting the implicit data model — which fields appeared, how records related, what state transitions the UI implied. Mapped each prototype screen to concrete Dataverse entities: the lead card became a Lead table, the quote builder became Quote + Quote Lines with product lookup, the pipeline view became the Opportunity Business Process Flow. Clarified ambiguities with the product owner where the prototype showed fields that didn't have a natural source of truth, or where the workflow implied a state that wasn't explicit. The Canva-to-data-model translation took two weeks of iteration before we had a schema stable enough to build on.

Model-Driven App — Lead to Cash

Built the full CRM on the extracted schema: lead qualification form with scoring rules, opportunity pipeline with BPF stages (Qualify → Discover → Configure → Propose → Close → Handoff), quote builder with product catalog integration and pricing calculations, and order creation triggering the F&O handoff. Custom C# plugins enforced business rules: quote line items recalculated on pricing changes, opportunity stage transitions validated required fields, order conversion locked the quote for audit integrity. Canvas Apps handled specific scenarios where model-driven forms were too rigid — mobile quote generation at customer sites, for example.

Dual-Write Integration — The Hard Part

Dual-Write was the architecturally correct choice: bidirectional real-time sync of customer, product, and pricing master data between CRM and F&O, with F&O as source of truth for financial entities and CRM owning the sales lifecycle. In theory, straightforward. In practice, the F&O side had accumulated significant custom code across related entities — validation handlers, pre/post-event logic, custom fields with business rules — that Dual-Write's standard mappings couldn't accommodate. Every CRUD operation on a synced entity risked triggering F&O-side code that threw exceptions the Dual-Write pipeline surfaced as cryptic sync errors. Resolving this required close collaboration with the F&O development team: reproducing each failure in isolation, tracing through F&O's X++ event handlers to identify which custom rule was firing, and jointly deciding whether to modify the mapping (filter the problematic field), adjust the F&O code (make the validation tolerant of CRM-originated records), or add middleware logic on one side or the other. For a few entities we ended up building custom post-sync flows that ran cleanup operations after Dual-Write completed its standard sync — belts and braces. Full integration stabilization took roughly three times the original estimate; most of the variance came from discovering F&O customizations one at a time as they hit production.

Dual-Write vs Virtual Entities — When to Choose What

This project crystallized when each pattern actually fits. Dual-Write makes sense when you need bidirectional real-time sync of operational data (both sides write and read), transactional consistency across CRM and F&O is critical, the entities involved are standard D365 ones with manageable customization on the F&O side, and you have access to the F&O team to resolve conflicts when they arise. Strengths: out-of-the-box mapping for standard entities, built-in retry, maintains referential integrity. Weaknesses: tightly coupled (custom code on either side can break the whole sync), hard to troubleshoot cryptic errors, full-record sync (no filtering), 'all or nothing' failure mode where one invalid field blocks the entire transaction. Virtual Entities make sense when the data lives authoritatively in F&O and CRM only needs to read it (or occasionally write), you don't want to duplicate data between systems, query-on-demand is acceptable (no real-time local access), and custom F&O code would block reliable Dual-Write. Strengths: zero data duplication, single source of truth, no sync pipeline to maintain, resilient to F&O-side customization. Weaknesses: performance depends on F&O availability, limited offline/disconnected scenarios, write-back is more complex, can't trigger CRM workflows on F&O data changes without polling. On this project we used Dual-Write for customers, products, and pricing (bidirectional sync was the whole point) but evaluated Virtual Entities for inventory levels and production status — those became Virtual Entities in a later phase precisely because the F&O-side customization on inventory transactions would have been a Dual-Write nightmare.

Outcome

Model-Driven CRM launched into production covering the full quote-to-cash flow as specified in the original Canva prototype. Sales team onboarded (~25 users) with training materials and adoption-tracking dashboards. Dual-Write sync stable on customers, products, and pricing after the joint F&O-team stabilization phase, with a documented runbook of edge cases and their resolutions. Virtual Entity pattern adopted as the architectural default for any future F&O integration where the F&O side has significant customization — lesson learned the hard way. Handoff documentation delivered covering the data model, integration architecture, and a written comparison of Dual-Write vs Virtual Entities trade-offs specific to this client's F&O customization profile.