Salesforce for Manufacturers: Quoting Without CPQ

Salesforce quoting for manufacturers almost never runs in Salesforce. The opportunity lives there. The account lives there. The quote — the thing the customer actually receives, with the configured part number, the tiered material pricing, the freight estimate and the margin the plant manager will argue about — lives in a spreadsheet on somebody’s desktop, gets pasted into a PDF, and comes back into the CRM as an attachment nobody can report on.

That is not a discipline problem. It is a tooling gap, and manufacturers landed in it for a specific reason worth understanding before you try to solve it.

Why manufacturers got left out of Salesforce quoting

The product that was supposed to solve this was Salesforce CPQ. It is no longer sold to new customers. Salesforce’s own position is precise and worth quoting accurately: CPQ is end of sale, not end of life — existing customers can keep using it, add users, renew and receive support, and no end-of-life date has been announced. But it sits in “a maintenance phase — supported, but no longer receiving new feature development.”

The successor is Revenue Cloud Advanced, part of the Agentforce Revenue Management suite. Salesforce is explicit that there is no forced migration. But for a manufacturer who does not already own CPQ, the practical situation is simple: the off-the-shelf answer to configured-product quoting is not available to you, and the thing replacing it is a platform-scale revenue lifecycle migration.

If you run a 40-person manufacturer quoting fabricated assemblies, or a distributor quoting off a price book with customer-specific tiers, neither of those was ever going to fit. You were too small for the enterprise suite and too specific for the generic one. So you kept the spreadsheet.

Your quoting logic is not generic, and that is the whole problem

Here is the thing nobody selling quoting software wants to say out loud: the reason no product fits your quoting is that your quoting encodes decades of accumulated decisions that are genuinely yours.

The minimum order quantity that applies to one product family but not another. The surcharge that keys off the current material index. The customer who has a contractual price hold until March. The rule that a certain finish adds four days of lead time and therefore changes the ship date on the quote. The discount authority that runs one way for distribution and another for direct.

A generic configure-price-quote tool handles roughly the first two of those and then asks you to bend the rest to fit its model. Which is how you end up with a half-configured CPQ instance and a spreadsheet — the worst of both, and a common enough ending that it deserves its own name.

Custom quoting logic was always the right answer for a manufacturer. It just used to cost a developer, a six-month project and a maintenance burden you couldn’t justify. That is the part that changed.

Start from the standard Quote object, not from zero

Salesforce already ships a Quote object tied to Opportunities, with Quote Line Items, syncing back to the opportunity, and versioning. It is not a configurator — it will not price a configured assembly or enforce your discount matrix — but it gives you the record structure, the related lists, the reporting surface and the PDF generation hook for free.

Everything below is built on top of that foundation rather than beside it. That matters more than it sounds: a quote that is a real record in Salesforce is a quote your pipeline reports can finally see.

Configured products without a product configurator

Most manufacturers do not need a full constraint-based configurator. They need the four or five dimensions that actually vary — size, material, finish, quantity break, an option or two — and the rules that say which combinations are legal.

That is a custom object with the option fields on it, a set of validation rules that reject impossible combinations, and an Apex class that assembles the part number and the price from the selections. When a rep picks 316 stainless in the 12-inch size with a passivated finish, the record builds the SKU, pulls the right cost basis and writes the line.

The rules that are genuinely hard — the ones where option A forecloses option C — are hard in any tool. The difference is that here you write them once, in your language, and they say exactly what your engineers say.

Pricing tiers that match how you really discount

Price books in Salesforce handle list pricing per product per currency. What they do not handle is your actual pricing: quantity breaks that differ by family, contracted customer pricing with expiry dates, a material surcharge that moves, freight estimated by weight and zone.

All of those are data plus a calculation. A custom pricing-rule object holding the tiers, a contract-price object with effective dates, and an Apex method that resolves the correct price for a given customer, product and quantity at quote time — then writes the result onto the line item so the quote is auditable after the fact.

Doing this in Flow is possible for the simple cases and quickly stops being possible for the rest; the breaking point is the same one covered in Flow vs. Apex — bulk operations, loops over related records and real transactional control. A pricing engine that runs on a 200-line quote needs Apex.

Margin approvals that know your floor

Manufacturers do not approve discounts by percentage off list. They approve by margin against a cost that moves.

The rule you actually want is: if this line drops below the margin floor for its family, route to the person who owns that family — and if it drops below the absolute floor, route to the owner regardless of amount. That is a calculation against current cost, evaluated per line and rolled to the quote, with routing that respects who actually owns what.

Standard approval processes route on fields, in sequence, with limited branching. Once your routing depends on computed margin and territory ownership at the same time, you are past what the declarative tools express cleanly — the same ceiling described in approval processes beyond Flow. Built properly, approval time drops because the quote arrives at the right person already carrying the number they need to decide.

The quote document, and the ERP on the other side

Two things finish the job.

The document: a generated PDF with your terms, your lead times, your part descriptions and the revision number — produced from the record, so the thing the customer holds and the thing your pipeline reports on are the same data. Version 3 is a record, not a filename.

The handoff: when a quote is accepted, the order should land in the ERP without anyone rekeying it. That is an integration — an authenticated callout, a field mapping, error handling for when the ERP rejects a line, and a retry path. It is ordinary work, and building a Salesforce integration end to end walks the shape of it. The rekeying step is where quote-to-order errors are born, and removing it is usually the single highest-value piece of this whole build.

What this actually takes now

Add it up and you have a custom object or two, a dozen fields, validation rules, an Apex pricing class with tests, an approval mechanism, a PDF template and one integration. As a staffed project that is a Salesforce developer for a couple of months, which is the estimate that has killed this build at mid-size manufacturers over and over — the cost math on hiring for it is why the spreadsheet survived.

What changed is not the requirements. It is who does the typing.

Sentinel gives your AI the ability to develop directly against your org — write the Apex, define the objects, deploy the metadata — so the work above becomes a series of conversations about your pricing rules instead of a hiring decision. You describe the margin floor policy; the AI writes the class and the tests and deploys it to a sandbox first.

The reason that is safe enough to do on a production org is ordinary and worth one paragraph: Salesforce deploys go to a sandbox with tests required before they go anywhere else, every change is logged with who made it and when, and a snapshot is taken before each deploy so you can get back. Sentinel does not stop your AI from doing something wrong — it makes what it did visible and recoverable, which is the property you actually need when the logic being written is your pricing. Teams who want the access model in detail can read how write access works.

Where to start

Not with the configurator. Start with the pricing resolution for one product family — the one your reps quote most and get wrong most. Get the tiers, the contract prices and the surcharge into records, get one Apex method resolving a correct price, and put it on a real Quote record.

That single piece is a week of conversations, not a quarter of a project, and it will tell you more about your own pricing rules than any requirements document. Then add the configuration for that family. Then the approvals. Then the ERP handoff. The spreadsheet retires one family at a time, which is also the only way anyone has ever successfully retired one.

The broader pattern — quoting as a build rather than a purchase — is covered in quote process automation if you want the non-vertical version.

Manufacturers have spent a long time being told their quoting is too specific for software. It was never too specific. It was just too specific to be worth a developer’s salary to encode. That constraint is the one that lifted.

---

Want to see what your quoting would look like built in your own org? Bring your ugliest pricing rule — the surcharge nobody can explain, the customer with three contracted tiers — and we’ll walk through what building it looks like. Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call