ERP and operational context
Dynamics 365 Finance & Supply Chain Management
- Released products
- Product masters
- Customers
- Units and currencies
- Inventory
- Sites and warehouses
- Cost data
- Relevant price inputs
- Manufacturing structures
- Production execution
- Features > Integrations > Dynamics 365 F&O CPQ
Mercura + Microsoft Dynamics 365 Finance & Supply Chain Management
CPQ for Microsoft Dynamics 365 Finance & Supply Chain Management
Configure complex products, calculate configuration-specific pricing, generate customer-ready quotes and transfer the approved result into Dynamics 365.
Mercura adds a sales-facing CPQ and product configuration layer around Microsoft Dynamics 365 Finance and Supply Chain Management — often referred to as Dynamics 365 F&O or FSCM — while your ERP remains responsible for the operational processes it already runs.
- Built for complex manufacturers
- Works with F&O / Supply Chain Management
- Internal, dealer and customer-facing configuration
Dynamics 365 F&O Example output
Sales quotation
- Customer
- Nordic Manufacturing
- Configured item
- Industrial system
- Status
- Validated
- Handoff
- Order-ready
The 30-second answer
What is CPQ for Dynamics 365 F&O?
CPQ for Dynamics 365 F&O connects Configure, Price, Quote with the product, customer and operational data managed in Microsoft Dynamics 365 Finance and Supply Chain Management. Instead of asking a salesperson to translate customer requirements manually into item numbers, dimensions, options, BOM components and prices, Mercura guides the user through the configuration and produces a structured commercial result that Dynamics 365 can execute.
Customer requirements → Product configuration → Pricing → Quote → Approval → Dynamics 365 quotation/order → Manufacturing
Dynamics 365 remains your ERP and supply-chain platform. Mercura handles the knowledge-intensive sales decisions that need to happen before the correct order can be created.
Important distinction
Dynamics 365 Supply Chain Management already has a product configurator. So why add CPQ?
Microsoft Dynamics 365 Supply Chain Management includes native product configuration technologies. Its constraint-based product configuration models can contain attributes, constraints, calculations, components, BOM lines and route operations, and configurable products can be used on sales quotations and sales orders. For many manufacturers, that native capability is valuable.
The question is not:
Can Dynamics 365 configure a product?
It can.
The better question is:
Where should product configuration stop, and where should the sales experience begin?
Dynamics 365 product configuration is closely connected to the operational product and manufacturing structure. Mercura CPQ focuses on:
- ✓ Guided selling based on customer needs
- ✓ Rules and engineering knowledge
- ✓ Configuration-specific calculations
- ✓ Commercial pricing logic
- ✓ Sales bundles and accessories
- ✓ Live 2D or 3D visualization
- ✓ Dealer or customer self-service
- ✓ Configuration-specific proposals
- ✓ Approval workflows
- ✓ Structured ERP handoff
You do not necessarily have to choose one configurator or the other. For many companies, the strongest architecture is a combination of Dynamics 365 operational product logic + Mercura sales configuration.
System responsibility
Keep Dynamics 365 as the operational system. Add the CPQ layer before the order.
A clean architecture does not duplicate your ERP. It gives every system a clear responsibility.
→context
M
Configure · Price · Quote
Mercura
- Guided selling
- Product selection
- Rules and constraints
- Formulas and calculations
- Configuration-specific pricing
- Bundles and accessories
- 2D / 3D visualization
- Quote generation
- Approvals
- Dealer/customer experience
→approved result
Execution
Dynamics 365 Finance & Supply Chain Management
- Sales quotation
- Sales order
- Released/configured product reference
- Order lines
- Configuration values
- Components
- BOM/manufacturing input
- Production and fulfillment
The architecture follows your Dynamics 365 implementation. Mercura does not require every manufacturer to restructure its products, BOMs or sales process around a predefined CPQ data model.
Native configuration vs. CPQ
Dynamics 365 Product Configurator or Mercura CPQ?
Dynamics 365 product configuration is closely connected to the operational product and manufacturing structure. Mercura CPQ focuses on everything required to turn a customer's requirement into a sellable, understandable and commercially correct solution.
| Requirement | Dynamics 365 SCM Product Configuration | Mercura CPQ |
|---|---|---|
| Product masters and released products | Core responsibility | Consumes or maps relevant data |
| Product dimensions | Core responsibility | Can expose dimensions in sales-friendly flows |
| Constraint-based configuration | Supported | Supported |
| BOM configuration | Core manufacturing capability | Can calculate or map commercial/component output |
| Route operations | Core manufacturing capability | Usually handed to SCM/engineering |
| Configure from sales order | Core capability | Can create an upstream sales experience |
| Guided selling from customer requirements | ERP-oriented | Core CPQ capability |
| Non-technical sales UX | Not the primary purpose | Core capability |
| Dealer configurator | Requires surrounding solution | Core use case |
| Customer self-service | Requires surrounding solution | Core use case |
| 2D / 3D visual configuration | Not the primary purpose | Core capability |
| Configuration-specific proposal documents | ERP document process | Core capability |
| Complex commercial calculations | Depends on ERP model | Core capability |
| Headless/custom frontend | Requires custom architecture | Native Mercura approach |
| CRM-led configuration | Requires integration | Designed for connected sales processes |
Use Dynamics 365 configuration alone when
Your configuration primarily exists to determine a valid ERP product variant, BOM and route, and your users are comfortable configuring products inside the Dynamics 365 process.
Add Mercura when
The customer requirement must first be translated into technical selections, commercial options, calculations, visualization or a customer-facing proposal before the ERP transaction can be created.
Combine both when
Dynamics 365 already contains valuable manufacturing configuration logic that should remain authoritative, while sales needs a simpler and more powerful experience around it.
Three ways Mercura can work with Dynamics 365 product configuration
There is no single correct F&O CPQ architecture. The right model depends on where your product knowledge already lives.
Pattern 1 — Dynamics 365 remains the configuration master
Your company already has mature Dynamics 365 product configuration models. Mercura provides the sales journey and captures the required inputs. The agreed integration translates those inputs into the Dynamics 365 configuration process where technically appropriate.
Best when:
- •Native SCM configuration models are mature
- •BOM and routing logic should remain in Dynamics 365
- •Rebuilding operational configuration logic would create unnecessary duplication
Pattern 2 — Mercura owns sales configuration
Mercura contains the rules required to determine the sellable configuration and produces the items, quantities, parameters and commercial values required by Dynamics 365.
Best when:
- •Existing configuration logic is in spreadsheets or people's heads
- •Sales configuration differs substantially from ERP product modelling
- •Guided selling and digital channels are priorities
- •The output can be mapped cleanly to released products, components or order data
Pattern 3 — Mercura → Engineering/CAD → Dynamics 365
Mercura automates the repeatable commercial configuration and passes structured parameters to engineering, CAD, PLM or another technical system. The validated engineering result then continues into Dynamics 365.
Best when:
- •Products are engineer-to-order
- •CAD still determines final geometry or manufacturing structure
- •CPQ can automate 70–90% of the decision process but engineering still approves the final design
Mercura can integrate with systems around Dynamics 365 rather than forcing every piece of product logic into one application.
The sales experience
Turn ERP product knowledge into a configuration your salesperson can actually sell
A customer does not normally arrive knowing product masters, configuration dimensions, item numbers, BOM variants, component codes, routes, warehouses or engineering attributes. They arrive with a requirement.
"We need a filling system for 3,000 bottles per hour, using this bottle size, with automatic capping and these hygiene requirements."
- 01
Understand the application
Capture capacity, environment, dimensions, installation requirements and customer preferences.
- 02
Select the right solution
Use rules to determine which product family, machine or system is suitable.
- 03
Configure it
Present only compatible options, components and accessories.
- 04
Calculate it
Calculate dimensions, quantities, engineering values, costs, surcharges and commercial prices.
- 05
Visualize it
Update images, drawings or interactive 3D as the configuration changes.
- 06
Quote it
Generate a proposal that explains what the customer is buying.
- 07
Send it to Dynamics 365
Transfer the approved configuration into the agreed quotation, order and manufacturing workflow.
From configuration to quotation
A quote your customer understands. Data Dynamics 365 can execute.
ERP data and customer-facing information serve different purposes. Mercura uses the structured configuration to produce sales documents containing the information the customer actually needs. The same configuration can simultaneously produce a more technical output for Dynamics 365. That removes the need to manually recreate the sold solution after the customer accepts the quote.
- ✓ Configured solution and product descriptions
- ✓ Selected options, quantities and dimensions
- ✓ Technical specifications, images and drawings
- ✓ Commercial prices, discounts and optional products
- ✓ Terms and conditions
Dynamics 365 Sales + Mercura CPQ + Finance & Supply Chain Management
Many enterprise Dynamics environments use more than one Dynamics application.
Dynamics 365 Sales
- Opportunity
- Account
- Contact
- Sales activity
Mercura
- Requirements
- Configuration
- Pricing
- Proposal
Dynamics 365 Finance & Supply Chain Management
- Quotation/order
- Product structure
- Production
- Inventory
- Fulfillment
- Financial execution
The exact system of record for customer, quotation and product information depends on your Microsoft architecture. Mercura does not require the commercial process to begin inside the ERP.
What we validate in your Dynamics 365 environment
There is no credible plug in any F&O instance and everything works promise. A proper CPQ integration starts by understanding how your Dynamics environment actually works.
Product model
- •Released products
- •Product masters
- •Product dimensions
- •Attributes
- •Existing product configuration models
- •Variants
Manufacturing
- •BOMs
- •Routes
- •Configure-to-order process
- •Engineer-to-order process
- •Production order requirements
Commercial model
- •Customers
- •Sales quotations
- •Sales orders
- •Pricing
- •Discounts
- •Currencies
- •Legal entities
Extensions
- •Custom fields
- •Custom tables
- •X++ extensions
- •Existing integrations
- •Industry solutions
Architecture
- •Finance
- •Supply Chain Management
- •Dynamics 365 Sales
- •Dataverse
- •Power Platform
- •CAD / PLM / PIM
- •Integration middleware
Operations
- •Sync frequency
- •Error handling
- •Retry strategy
- •Logging
- •Reconciliation
- •Ownership
Technical integration
What data can Dynamics 365 F&O and Mercura exchange?
Dynamics 365 finance and operations apps expose several integration patterns. The correct interface depends on volume, latency requirements, your existing extensions and whether the process is synchronous or asynchronous. The final contract is agreed at field level during implementation.
| Data | Direction | Typical approach | Purpose |
|---|---|---|---|
| Released products | Dynamics 365 → Mercura | Public data entity / OData / integration layer | Reuse ERP product master |
| Product attributes | Dynamics 365 → Mercura | Data entity / mapped integration | Configuration context |
| Customers | Dynamics 365 → Mercura | Public data entity / OData | Customer-specific selling |
| Units and currencies | Dynamics 365 → Mercura | Data entities | Consistent commercial calculations |
| Pricing inputs | Dynamics 365 → Mercura | OData, service or mapped integration | Reuse ERP commercial data |
| Inventory context | Dynamics 365 → Mercura | OData/service where required | Availability-aware selling |
| Configuration | Mercura → Dynamics 365 | Data entity, mapped endpoint or custom service | Preserve what was sold |
| Sales quotation | Mercura → Dynamics 365 | Data entity / service | Continue ERP quotation flow |
| Sales order | Mercura → Dynamics 365 | Data entity / service | Create execution-ready order |
| Components / BOM input | Mercura → Dynamics 365 | Implementation-specific integration | Configure-to-order handoff |
| Engineering parameters | Mercura → Dynamics 365 / CAD / PLM | API mapping | Technical downstream automation |
| Mercura reference | Mercura → Dynamics 365 | Mapped field | End-to-end traceability |
OData, Data Management or custom services?
Dynamics 365 supports multiple integration patterns, and they should not be treated as interchangeable.
OData
Finance and operations apps expose public data entities through an OData REST endpoint.
- •Querying master data
- •Customers
- •Products
- •Smaller synchronous transactions
- •CRUD operations against suitable public entities
Data Management Framework
The Data Management Framework supports data entities and data packages for import, export and integration.
- •Higher-volume synchronization
- •Structured imports and exports
- •Bulk data
- •Scheduled integration
Recurring integrations
Recurring integrations can exchange documents or files between finance and operations apps and external applications.
- •Asynchronous integrations
- •Scheduled document exchange
- •Existing data-management processes
Custom services and extensions
Not every company's Dynamics 365 implementation can be represented by standard public entities. Custom services or extensions may be the right approach where the process depends on custom tables, fields, business logic, specialized pricing, product configuration logic, company-specific order creation or manufacturing processes.
Mercura's integration design starts with the business process and selects the appropriate Dynamics 365 interface — rather than promising that every implementation is a one-click OData connection.
Microsoft Entra ID and API authentication
Dynamics 365 finance and operations integrations can use OAuth 2.0 and Microsoft Entra application identities for authenticated system-to-system communication. The exact security architecture depends on the integration pattern and your Dynamics 365 environment.
During implementation we define:
- ✓Application identity
- ✓Required permissions
- ✓Dynamics 365 security mapping
- ✓Environment separation
- ✓API access
- ✓Logging
- ✓Error handling
- ✓Credential management
Where should pricing live in a Dynamics 365 CPQ architecture?
There is no universal answer. Trying to duplicate every Dynamics 365 price rule inside CPQ is usually just as undesirable as forcing every configuration-specific calculation into ERP.
Option 1 — Dynamics 365 owns pricing
Mercura determines the configuration while the relevant commercial price comes from Dynamics 365.
Best when: ERP already produces the final price required by the sales process.
Option 2 — Dynamics 365 provides commercial inputs
Dynamics 365 provides item prices, customer information or other commercial inputs. Mercura calculates the configuration-specific part.
Base machine + width surcharge + stainless-steel factor + high-capacity motor + controls package + installation − customer discount = configured selling price
Best when: ERP pricing works well for standard products but the configured solution introduces formulas and option-dependent pricing.
Option 3 — Mercura calculates the configured price
Mercura owns the complete CPQ pricing model and sends the approved selling price to Dynamics 365 together with the order structure.
Best when: Price depends heavily on configuration parameters, calculations, customer requirements or product relationships.
Pricing ownership is an architecture decision, not a CPQ feature checklist.
From F&O CPQ to BOM, routing and production
For manufacturers, producing the quotation is only half the problem. Operations also needs to know: what exactly did we sell, and what should we build?
Pattern 1 — Existing released product or variant
Mercura identifies an existing sellable/manufacturable product or variant.
Output: Product + configuration reference + quantity + price
Pattern 2 — Native Dynamics 365 configurable product
Dynamics 365 product configuration remains responsible for generating the operational product structure. Mercura supplies the sales-facing configuration context required by the agreed process.
Output: Configuration parameters → Dynamics 365 configuration
Pattern 3 — Configuration-specific component structure
Mercura determines which components and quantities belong to the sold configuration. The result is mapped into the agreed Dynamics 365 manufacturing process.
Output: Parent product + components + quantities + configuration values
Pattern 4 — Engineering-to-order
Mercura creates the commercial configuration and sends structured parameters into CAD, PLM or engineering. The resulting engineering structure becomes the manufacturing definition used downstream.
Output: CPQ parameters → engineering → final production structure → Dynamics 365
Implementation
A practical path from one configured product to production
The integration is one workstream. The bigger win comes from making product, pricing and sales knowledge explicit enough to automate.
- 01
Model one representative product
Choose a product that contains enough complexity to prove the architecture. Capture customer requirements, options, dependencies, calculations, pricing, components and expected Dynamics output.
Output: Validated CPQ pilot model
- 02
Map Dynamics 365
Identify the required data entities, products, customers, pricing inputs, quotation/order objects, manufacturing output and extensions.
Output: Field-level integration specification
- 03
Build the sales journey
Design the experience around the people using it: internal sales, engineers, dealers and customers. Add rules, visualization, documents and approvals.
Output: Testable end-to-end sales workflow
- 04
Validate ERP handoff
Compare the result from Mercura against the expected Dynamics 365 transaction and manufacturing structure.
Output: Reconciled quote-to-order process
- 05
Scale
Expand product family by product family while keeping product and integration governance explicit.
Output: Maintainable CPQ rollout
Where it pays off
Use cases with enough complexity to justify CPQ
Industrial equipment
Configure capacities, dimensions, materials, motors, control packages and accessories.
Buying signal: Sales regularly needs engineering to validate a quote.
Machinery
Turn requirements into a machine, module structure, options and production input.
Buying signal: Every order requires several technical decisions before an item can be selected.
Building products
Calculate sizes, materials, mounting requirements, finishes and installation options.
Buying signal: The final product depends on dimensions and formulas rather than simple SKU selection.
Process systems
Configure multiple products into one engineered commercial solution.
Buying signal: Sales is really selling a system rather than an individual item.
Dealer sales
Give distributors controlled access to product knowledge, configuration and pricing.
Buying signal: Dealer growth creates an increasing support load for internal engineering and sales teams.
Engineer-to-order
Automate the repeatable 80% of product selection before engineering completes the final technical work.
Buying signal: Engineers spend significant time answering the same configuration questions for sales.
Decision support
Dynamics 365 F&O CPQ questions, answered
What is Dynamics 365 F&O CPQ? +
Dynamics 365 F&O CPQ is a Configure, Price, Quote solution connected with Microsoft Dynamics 365 finance and operations applications. It helps sales teams turn customer requirements into valid configurations, prices and quotations before sending the approved result into Dynamics 365 for order and operational execution.
Is F&O the same as Dynamics 365 FSCM? +
The terminology has changed over time. Dynamics 365 F&O is still widely used to describe the Dynamics 365 finance and operations platform and ecosystem. Microsoft currently markets Dynamics 365 Finance and Dynamics 365 Supply Chain Management as separate applications. Some implementation partners and customers use FSCM or F&SCM as shorthand for Finance + Supply Chain Management. For CPQ buyers, these terms frequently describe the same underlying integration landscape.
Does Dynamics 365 F&O have a product configurator? +
Dynamics 365 Supply Chain Management does. Microsoft supports predefined variants, dimension-based configuration and constraint-based product configuration. Constraint-based product configuration models can contain attributes, constraints, calculations, components, BOM lines and route operations and can be used when configuring products from sales quotations and orders. That means external CPQ should not automatically replace the native configurator. Mercura is particularly relevant when you also need guided selling, customer-facing configuration, visualization, sophisticated commercial logic or richer quote automation.
Microsoft: Product configuration models overview →What is the difference between Dynamics 365 Product Configurator and CPQ? +
The Dynamics 365 configurator primarily helps define a valid product and operational structure inside Supply Chain Management. CPQ covers the broader sales problem: what does the customer need, what can we sell, what should it cost, how should we present it, and what should ERP execute. Companies can use either system independently or combine them.
Can Mercura work with our existing Dynamics 365 product configuration models? +
Potentially, yes. The correct architecture depends on how those models are structured and how they should participate in the sales process. We first determine whether the best approach is to keep native Dynamics configuration authoritative, model the sales configuration in Mercura and map the output into Dynamics, or split responsibilities between the two. We do not recommend rebuilding mature ERP configuration logic without a business reason.
Can Mercura create Dynamics 365 sales quotations and sales orders? +
Yes, where included in the agreed integration. Mercura can map an approved configuration into the relevant Dynamics 365 quotation or sales-order process, including references, products, quantities, commercial values and configuration information. The exact interface depends on your available data entities, extensions and order structure.
Can Mercura send BOM information to Dynamics 365? +
Yes, but send a BOM can mean several different things in Dynamics 365. The implementation must establish whether the sold configuration should select an existing variant, trigger an existing product configuration model, reference an existing BOM, create configuration-specific component data, or feed engineering before the final BOM exists. We design the integration around the manufacturing process rather than assuming every configurable product should create a new BOM.
Where should pricing live? +
It can remain in Dynamics 365, be split between Dynamics 365 and Mercura, or be calculated in Mercura. The correct choice depends on whether your pricing is primarily ERP/customer based or configuration based.
Does sales have to work inside Dynamics 365? +
No. Mercura can power internal sales applications, Dynamics-connected workflows, dealer portals, customer portals, website configurators and custom applications. The same configuration engine can serve different channels while Dynamics 365 remains the operational backend.
How does Mercura integrate with Dynamics 365? +
Common Microsoft integration technologies include OData and public data entities, Data Management Framework, REST APIs, recurring integrations, custom services and extensions, and Microsoft Entra ID authentication. The exact architecture depends on the data volumes, latency requirements, extensions and business process.
Can Mercura also connect with Dynamics 365 Sales? +
Yes. In a broader Microsoft architecture, Dynamics 365 Sales can own CRM activity and opportunities, Mercura can manage configuration and quoting, and Finance & Supply Chain Management can handle downstream order, manufacturing and financial processes.
Official technical resources
Technical content last reviewed 30 August 2026. Validate assumptions against your Dynamics 365 edition, release and extensions.
Explore the capability stack
Go deeper on the parts of CPQ that matter
See it on your process
Bring us one real Dynamics 365 quote. We will map the CPQ architecture around it.
The fastest way to evaluate Dynamics 365 CPQ is not with a generic feature checklist. Bring one representative product and one real quotation process. We will map customer requirement → configuration → pricing → quote → Dynamics 365 → manufacturing and show you which responsibilities should remain in Finance & Supply Chain Management and which ones Mercura can automate.
Request a CPQ demo