Product catalogue setup

What it does

The product catalogue is the set of records sellers pick from when adding line items to opportunities, quotes, orders and invoices: unit groups and units, products, price lists and price list items, and optional discount lists, product families, bundles and properties. Pricing on a line comes from the price list item unless you override it.

Key facts

The build order matters and it is not negotiable: discount lists, then unit groups and units, then products (families and bundles as needed), then price lists, then price list items, then nominate a default price list.
Every product must be linked to a unit group and a default unit. You cannot create a usable product first and sort units out afterwards.
Products have a draft and an active (published) state. The Create product in active state setting flips new products straight to active; it is off by default, is organisation-level, and doesn't apply to products under a product family.
Product families, bundles and product properties are Sales Hub features. A Sales Professional catalogue is a flatter list.
Default limits: Max number of products in a bundle is 15, and Max number of properties of a product or bundle is 50. Both are configurable in product catalogue settings.
Discount calculation method is either Line item or Per unit, and Line item is the default. This changes the arithmetic on every discounted line.
System pricing calculation is on by default. Turning it off hands pricing to custom logic — a plugin — and the platform stops calculating line amounts for you.
Make price list optional allows lines without a price list; Allow selection of default pricelist picks a default price list using territory-based rules. Both are off by default.
The default price list is the fallback the system uses when the price list on the opportunity or order has no entry for that product.
Price list items can be created from either the product record or the price list record — same data, two entry points, which is how duplicates creep in.

When to use / skip

If the client sells anything with a fixed catalogue and stable pricing, build it properly and early. It underpins quote accuracy, revenue reporting and any downstream ERP integration.

Where it gets contentious is complex pricing. The out-of-the-box engine handles list price, quantity-based discount lists, percentage and amount discounts on the line, and that's roughly it. Tiered contract pricing, customer-specific rate cards beyond one price list per customer, configure-price-quote logic — none of that is in scope, and the honest options are a CPQ product, a pricing plugin with system pricing turned off, or keeping pricing in the ERP and treating Dynamics as the opportunity record only. Decide this in design, not in UAT.

For clients selling services or one-off deals, consider skipping the catalogue and using write-in products. It costs you reporting by product, and you should say so, but it beats maintaining a catalogue nobody keeps current.

Configuration decisions

Catalogue products, write-in products, or both — and whether write-ins are allowed on quotes that go to customers.
Whether pricing stays with the system engine or moves to custom logic, because that decision drives whether line amounts are ever calculated for you again.
How many price lists you need, and what determines which one lands on an opportunity: currency, territory, customer segment or manual choice.
Unit group design. One "Default" group with a single unit is fine for most clients; per-product unit groups are a maintenance burden that has to be justified.
Discount calculation method, per unit or line item, agreed with finance rather than assumed.
Whether the catalogue is mastered in Dynamics or in an ERP and synchronised, and if synchronised, which system wins on price.

Gotchas

Build the pieces out of order and you'll be re-keying. Products with no unit group can't be saved usefully, and price list items can't exist before their price list.
Price lists are currency-specific. Multi-currency clients need one price list per currency, and a missing one means sellers get no price rather than a warning.
Retiring a product doesn't clean up existing lines. Historical quotes and orders keep the retired product, which is correct but confuses reporting.
Turning off system pricing is close to a one-way door. Everything that depended on the calculated fields — rollups, reports, forecasts — now depends on your plugin behaving.
The default price list is quiet. When it's wrong, sellers get a price rather than an error, and nobody notices until an invoice is disputed.
Bundle and property limits are defaults, not laws of nature, but raising them has a real effect on form performance on the add-products experience.

Consultant notes

Get finance in the room for the discount method and price list design. Sales will agree to anything; finance is the party that later disputes the numbers.
Demo adding products to an opportunity with a real price list on day one of UAT. It is the single most-used screen and the fastest way to surface a pricing gap.
Import the catalogue rather than hand-keying it, and keep the import files in source control — you'll need them for every environment.
Push back on "we'll just build the pricing rules ourselves". Ask what happens when the plugin author leaves.
Before go-live, check that every active product has a price list item in every price list a seller can select, and that every currency in use has a price list.

Worth revisiting if the client's pricing model changes, or before any CPQ or ERP integration lands.