If you manufacture configurable equipment and quote it from Salesforce CPQ, you have probably seen the gap between what the quote says and what the shop floor can build. Salesforce no longer sells Salesforce CPQ to new customers. As a result, many manufacturers are asking whether their current product modeling will hold up for the next five years. This article explains where Salesforce CPQ's bundle architecture runs into limits for manufacturing work. It also covers what good looks like for nested bundles, bills of materials, and configure-to-order quoting, and how to weigh your options calmly after the end-of-sale news.
TL;DR
- Salesforce CPQ is end of sale, not end of life. Existing customers can keep using it, renew, add users, and receive support. Salesforce has not announced an end-of-life date, and no one is forcing a migration.
- Salesforce CPQ was designed as a tool for commercial bundles and subscription quotes. It models sellable bundles well. It was not designed to produce a manufacturing bill of materials (BOM) or routings.
- The practical limits appear in four places: deep nested bundles, components that expand based on option choices, cost rollup across assembly levels, and anything that needs engineering or ERP (enterprise resource planning) data in real time.
- Most manufacturers close that gap with custom development, middleware, or engineers re-entering data by hand. That work is where the real cost lives, not in license fees.
- You have more than two choices. If your configurations are shallow and your production data is stable, staying put is defensible. If sales configurations must become buildable structures, you need a CPQ for manufacturing that models assemblies, materials, and operations as a hierarchy and hands that structure to ERP.
Why Manufacturers Are Re-Examining Salesforce CPQ Now
Salesforce CPQ (configure, price, quote) is still supported, renewable, and usable. What changed is where Salesforce is investing. Its strategic development has moved to Revenue Cloud Advanced, and Salesforce CPQ now gets limited new feature development. Moving from Salesforce CPQ to Revenue Cloud Advanced is not an upgrade. It is a reimplementation with a different data model and a different way of configuring products.
For a software company selling subscriptions, that is a manageable roadmap question. For a manufacturer, the stakes are higher. You may already be stretching the product model to represent machines, options, subassemblies, and installed services. If so, you now have to decide whether to rebuild that stretched model on a new platform or rethink the quoting layer entirely.
To be fair, Salesforce CPQ does a lot well. It is a capable tool for moderately complex catalogs, discount schedules, approval workflows, and subscription terms, and it fits comfortably inside Salesforce CRM. The limits appear when the configuration has to be manufacturable.
Where Nested Bundles Start to Strain
Salesforce CPQ models products as bundles with options, option groups, and rules. That structure is a commercial hierarchy: what the customer buys and what appears on the quote. This article focuses on the manufacturing side of the broader Salesforce CPQ limitations for configurable products. A manufacturing hierarchy is different. It describes what gets built, from the finished assembly down through subassemblies, components, raw materials, and purchased parts.
The two hierarchies overlap, but they are not the same. The friction grows as the hierarchy gets deeper.
Depth, dependency, and rule sprawl
Nested bundles work until dependencies start running in several directions at once. For example, frame size limits the drive option. The drive option limits the control package. The control package changes the wiring harness and the certification documents. You can express that in product rules, price rules, and constraint rules, but the rule set grows faster than the catalog does. As catalogs grow to thousands of SKUs, nested bundles, and hybrid offerings that mix physical products, services, and subscriptions, rule sets tend to get harder to maintain. Large quotes can also run into governor limits on deep nested bundles.
The maintenance cost matters as much as the performance cost. If only the person who wrote the logic can safely change it, every new product variant becomes a project instead of an update.
Calculation customization and the specialist dependency
When pricing logic goes beyond what the standard engine can do, it usually moves into the Quote Calculator Plugin (QCP) or Apex code. That is a legitimate extension point, and it works. It also means your pricing now lives in code that an admin cannot safely edit. That code must be regression-tested against every release, and it must be redesigned entirely if you later move to a different platform. This is where manufacturers usually come to depend on consultants, especially if they need cost rollups, margin floors by assembly level, or regional supply factors.
BOMs and Routings: The Capability That Isn't Really There
Salesforce CPQ produces a quote. On its own, it does not produce a multi-level manufacturing BOM that keeps parent-child relationships intact, and it does not produce routings.
Two definitions matter most here:
- Bill of materials (BOM): the hierarchical list of every component, subassembly, raw material, and purchased part needed to build a configured product. It includes quantities and the parent-child relationships between assembly levels.
- Routings: the manufacturing method. A routing sets out which operations happen in what order, at which work centers, and with what setup and run times. It also includes inspection points and quality gates.
If the BOM is the recipe, the routing is the method. Production planning needs both, and it needs them as structured data, not approximations.
In practice, manufacturers bridge the gap by hand or with custom integration. Sales configures the product in Salesforce CPQ, and then engineering re-creates the structure in ERP or in spreadsheets. Each re-entry step is a chance to miss a component, get a lead time wrong, or let the quoted margin drift from the actual build cost. Teams that try to automate this bridge usually turn to middleware, custom code, or copies of ERP data in custom Salesforce objects. They then inherit the ongoing job of keeping two complex data structures in sync.
Why ERP integration is the real test
Salesforce CPQ performs well inside the Salesforce CRM ecosystem. The strain shows when quoting depends on data that lives in ERP, such as live component availability, current standard costs, manufacturing lead times, and real BOM structures. A quote that looks correct in CPQ may already be out of date when it is sent if the ERP data has changed.
So be specific when you evaluate ERP integration. Ask these questions:
- Does the CPQ read production data directly from ERP?
- What does it write back?
- Does it need middleware to do either?
- Does it allow only validated configurations to reach ERP?
An API endpoint is not the same as a supported handoff of BOM, routing, and work breakdown structure (WBS) data.
Configure-to-Order and Engineer-to-Order Realities
In configure-to-order (CTO) work, the product is built from a set of options that engineering has already validated. The configurator's job is to prevent invalid combinations and turn the selection into a buildable structure. In engineer-to-order (ETO) work, some engineering happens for each deal. The configurator then has to handle parameters, formulas, and generated documents rather than fixed option lists. For a fuller breakdown of engineer-to-order vs. configure-to-order and how each maps to Salesforce CPQ, see the dedicated guide.
For manufacturing, the key point is that Salesforce CPQ handles the commercial side of CTO reasonably well: option selection, validation, pricing, and approvals. It does not inherently handle the production side, and the production side decides whether an order can be released. ETO pushes further still, because quotes often have to include technical documents, drawings, and project structures.
At this point, many manufacturers stop asking which CPQ has more features. They start asking where their configuration logic should live.
How Experlogix CPQ Approaches Manufacturing Configuration
Experlogix CPQ is built for this kind of problem. The architecture matters more here than the feature list.
Products are modeled as hierarchical assemblies. The BOM Designer models assemblies, materials, and operations as a structured hierarchy. Usage types (Line Item, Assembly, Material, and Operation) drive the structure. You can drag and drop assemblies, materials, and operations under parent options, including subassemblies. The hierarchy is stored in the configuration XML so ERP can use it downstream. CRM users can see the same structure in a BOM viewer instead of asking engineering to explain it.
The same rules that validate the configuration during quoting also assemble the BOM and routing. Each selected option maps to its components, subassemblies, and operations. The result is a complete multi-level BOM and routing that match what was sold. The production package is then pushed as structured data into Microsoft Dynamics 365 Finance & Supply Chain Management or Business Central. It includes the bill of materials, the routings, and, for project-based work, the work breakdown structure. Only configurations the rules engine has validated are sent, so production does not start from an order that cannot be built.
For Salesforce CRM customers, Experlogix CPQ runs embedded in Salesforce. Reps configure, price, and quote without leaving the CRM, and data flows in both directions between CPQ and CRM. Experlogix does not only read from Salesforce. It also writes back configuration details, pricing calculations, and approval status. Cloud Connect synchronizes quotes, orders, and approvals across CRM and ERP without custom code, and it can write to standard or custom Salesforce objects without developers. Salesforce CRM stays the system of record for customer and opportunity data, while the heavy configuration logic runs in an engine built for it.
Other capabilities relevant to manufacturing quotes:
- Multi-level BOMs, nested configurations, and dependency rules
- Guided selling that steers users toward valid configurations
- Automatic generation of CAD drawings, BOMs, and supporting technical documents, which matters in regulated industries
- Shared mapping trees, so you can reuse one product model across sales channels, customer segments, or regions without rebuilding the logic
- Low-code rule ownership, so business users control logic changes and new product variants
When a rule changes, you update the logic once, and every new configuration reflects the change.
When Salesforce CPQ is still the right call
Salesforce CPQ remains a reasonable fit when your configuration needs are low to moderate, your quoting happens entirely inside Salesforce, and your workflows are fairly simple. The case for change is also weak if:
- Your products are mostly standard.
- Engineering maintains BOMs directly in ERP, and quotes do not depend on them.
- Your rule set is stable.
The same applies if you are already committed to a Revenue Cloud Advanced reimplementation with executive sponsorship and budget. Starting a second transition partway through rarely helps.
The Bottom Line on CPQ for Manufacturing
Salesforce CPQ is end of sale, not end of life. You can renew, add users, and keep running it with support, and no end-of-life date has been announced. The pressure manufacturers feel is not a deadline. It is the growing distance between a commercial bundling tool and what manufacturing quotes actually require.
The decision comes down to five questions:
- Can your CPQ model nested bundles as deep as your real products require, without a sprawling rule set that only a specialist can maintain?
- Does a validated configuration automatically produce a multi-level bill of materials and routings, with parent-child relationships intact?
- Does cost roll up accurately at every assembly level, so you know the margin when you quote rather than days later?
- Does your ERP integration move structured production data, or a parts list that someone has to restructure?
- Can your own admins change the logic when a component is replaced?
When configurations become buildable definitions automatically, sales and engineering stop duplicating work. Production planners schedule from the same record the customer approved, and finance sees material and labor costs at quote time instead of after the fact. That outcome is worth designing for, whichever platform you choose.
A practical next step is to take your three hardest real quotes from the last year, not demo products, and map each one from start to finish. Record every option dependency, every manual engineering step, every spreadsheet, and every ERP field someone re-entered. Then clean the underlying data and confirm that item numbers and units of measure match between systems. Finally, decide who owns the configuration rules going forward. That map will tell you more about your CPQ requirements than any feature comparison.
FAQ
Can Salesforce CPQ generate a manufacturing BOM?
Not on its own. Salesforce CPQ models commercial bundles for quoting. It does not produce a multi-level manufacturing BOM with parent-child relationships intact, and it does not produce routings. Manufacturers usually fill the gap by re-entering data in ERP or spreadsheets, or with custom integration and middleware.
Can Experlogix generate BOMs and routings from a validated configuration?
Yes. The same rules that validate a configuration during quoting also assemble the BOM and routing, so the output is a complete multi-level BOM and routing that match what was sold. That production package, plus the work breakdown structure for project-based work, is pushed into Microsoft Dynamics 365 Finance & Supply Chain Management or Business Central. Only validated configurations are sent.
What is the difference between a BOM and a routing?
A BOM is the hierarchical list of components, subassemblies, raw materials, and purchased parts needed to build a product, with quantities and parent-child relationships. A routing is the manufacturing method: the sequence of operations, work centers, setup and run times, and inspection points. If the BOM is the recipe, the routing is the method.
What should manufacturers test in CPQ-to-ERP integration?
Test whether the CPQ reads production data such as costs, lead times, availability, and BOM structures directly from ERP. Check what it writes back, whether it needs middleware, and whether it sends only validated configurations. Also confirm that it passes structured BOM, routing, and WBS data rather than a flat parts list that someone has to restructure.
Why do commercial bundles and manufacturing BOMs diverge?
They describe different things. A commercial bundle describes what the customer buys and what appears on the quote. A manufacturing BOM describes what gets built, from the finished assembly down to purchased parts. Option choices can change the components, subassemblies, and operations in ways a sales bundle does not capture, so the two drift apart unless one set of rules generates both.
See how Experlogix CPQ helps manufacturers model multi-level assemblies, generate BOMs and routings from the same rules used to quote, and hand structured production data to ERP.
