Visual CPQ connects a custom-product experience to the systems that decide what can be sold, what it costs and what a quote actually commits to. The 3D view can explain a choice. It should not become the authority for product validity, bill of materials, price, approval or order data.
A sound design moves through explicit states: a user proposes choices; product rules resolve a valid configuration; a visual adapter renders that resolved state; pricing evaluates it in a named commercial context; BOM and quote mappings derive their own outputs; and a governed transaction records the result. Every handoff carries stable identifiers and versions. If a later stage cannot prove what it received, it rejects or returns the configuration for repair instead of guessing from labels or pixels.
This guide covers the price-and-quote architecture in that chain. Use 3D product configuration software versus visual CPQ for the category comparison. Use the manufacturing configurator guide when the scope continues into manufacturing-specific BOM and ERP handoffs. The broader 3D product configurator pillar defines configurator rules, visuals and outputs.
Visual CPQ joins distinct system truths
The word “visual” can make CPQ sound like a viewer feature. It is more useful to treat visual presentation as one consumer of product state. The catalog identifies products and options. The rule layer decides whether a candidate combination is valid. The visual layer maps accepted IDs to geometry and materials. Pricing applies commercial context. BOM mapping translates the configuration into components or output lines. The quote workflow records parties, terms, approvals, revisions and status.
Those responsibilities may live in one platform or several connected services. The ownership still needs to be explicit. A material name such as “sand” is not a durable option ID. A mesh called leg_02 is not a manufacturing part number. A number displayed beside the model is not necessarily an approved price. A PDF is not the quote system of record merely because it looks final.
The following Visual CPQ integrity chain is an original Double Edged architecture framework. It is a discovery and acceptance tool, not a claim that every company needs seven separate applications.
| Gate | Authoritative question | Minimum handoff | Evidence before the next gate |
|---|---|---|---|
| 1. Product identity | Which sellable family, market and revision is being configured? | Stable product and option IDs | Catalog owner confirms IDs, lifecycle state and market scope |
| 2. Rule resolution | Is this candidate state valid, and what changed during resolution? | Resolved selections, reasons and rule-set version | Positive, negative and boundary cases return explainable results |
| 3. Visual mapping | What geometry, material and view represent the resolved IDs? | Asset-map version and visual state | Reference views agree with the resolved summary |
| 4. Price evaluation | What amount applies for this customer, channel, quantity, currency and effective time? | Price request ID, context, response and pricing version | Authoritative service returns an attributable result or a defined failure |
| 5. BOM and line mapping | Which commercial and operational lines follow from the configuration? | Mapping version, component IDs, quantities and exceptions | Output reconciles to an approved representative configuration |
| 6. Quote transaction | What is being offered, to whom, under which terms and approvals? | Quote ID, revision, status, validity window and snapshot reference | Generated document and transaction data agree |
| 7. Downstream handoff | What must cart, CRM, ERP or order systems receive? | Immutable configuration reference plus required payload | Receiving system can retrieve and verify the accepted snapshot |
This chain exposes a common source of rework: teams integrate a viewer directly with a price field and postpone rule ownership, versioning and output mapping. That shortcut works only while every option is independent, every price is static and nobody needs to explain an old quote. Custom products rarely stay that simple.
The public Custom Configurator Scope and Budget-Driver Estimator maps product rules, assets, visualization, integrations, pricing, outputs and operating ownership into a transparent complexity profile and recommended next step.[8]
Define the configuration contract before the interface
Start with a machine-readable configuration object whose fields have business owners. It should identify the product family and revision, selected option IDs, market, units, locale and the rule version used to resolve the state. Keep display labels outside the identity contract. Labels change for translation and merchandising; identifiers should survive those changes.
JSON Schema provides a vocabulary for asserting the structure of JSON instances. Its validation vocabulary includes required and dependentRequired, which can express that one field must be present when another appears.[1] That is useful for payload shape, such as requiring a currency with a price context. It does not by itself decide whether an engineered span is safe, whether a finish is available in one market or whether a discount is allowed. Those remain domain decisions.
Give domain rules names, owners, effective dates and examples. The Object Management Group describes Decision Model and Notation as a common notation intended to bridge business decision design and technical implementation.[2] A team may use DMN decision tables, code, a CPQ rules engine or another governed representation. The important requirement is that a product manager can inspect the decision while engineering can execute and test the same meaning.
Separate three states in the API and event model:
- Candidate state contains the user’s proposed change.
- Resolved state contains accepted selections, automatic changes, rejections and explanations.
- Committed snapshot freezes the accepted state and versions for price, quote or downstream use.
The 3D scene and UI consume the resolved state. They do not independently repair invalid selections. If choosing a longer worktop requires a third support, the rule result should add or require the support, identify why, and send the resulting component ID to both the summary and visual adapter.
Keep the 3D view downstream of validity
A viewer should make product consequences legible: proportions, component presence, finish, orientation and selected features. It should receive a declarative visual state, not infer sellability from object visibility. Otherwise a rendering bug can change the apparent configuration without changing the quote, or an artist’s scene-name edit can break commercial logic.
Use an explicit mapping from resolved product IDs to asset IDs, material variants, transforms, visibility states and camera cues. Version that mapping independently from the rules. A rule update may make a combination invalid without changing any model. An asset correction may improve geometry without changing the sellable product. Separate versions let the team test and release each change without pretending they are the same artifact.
Define visual failure behavior. If a mapped asset is missing, decide whether the user sees a fallback image, a clearly marked incomplete preview or a blocked configuration. Do not leave a stale component on screen while the summary and price have moved on. For quote-bearing experiences, a useful acceptance rule is simple: the visible product, text summary, priced lines and configuration reference must all identify the same resolved state.
Price the commercial context, not the pixels
A price request should be reproducible from data. Send the resolved configuration reference and the context the pricing authority needs: customer or segment when permitted, channel, market, quantity, currency, effective date, contract reference and any approved promotion or discount inputs. The response should return its own identifier, amount components, currency, tax treatment if applicable, effective or expiry information, pricing version and reasons for adjustments that the user or approver is allowed to see.
Salesforce’s official CPQ training describes price rules as if/then logic that can conditionally update fields on a quote line, quote-line group or quote.[3] That vendor example illustrates why the visual client should not recalculate an “equivalent” price from what is visible. Pricing can depend on quote and account context that does not belong in the scene.
Choose a display policy for every non-happy path. When the price service times out, the interface might retain a timestamped amount, hide it, mark it pending or switch to a request-for-quote path. The correct choice depends on the commercial policy and risk. What matters is that the experience never presents an old or estimated value as newly authoritative.
Treat repricing as a named event. A saved configuration reopened after a catalog, rule, customer agreement or currency change should not silently inherit the old amount. Compare versions, explain material changes, and require a new price response before creating or accepting a quote when policy demands it.
Derive BOM, sales lines and visuals from one snapshot
A configured product may produce several related outputs that are not interchangeable. The visual state describes what to render. Sales lines describe what is offered and priced. A manufacturing or fulfillment BOM may expand assemblies, quantities and service components. A customer-facing summary may deliberately group those details.
Oracle’s current CPQ REST catalog documents BOM mapping-rule setup endpoints separately from its Calculate Price action, which lets an external application query CPQ for pricing information.[4] That is a vendor-specific API, not a universal topology, but the separation is useful: BOM derivation and price evaluation need distinct contracts and tests even when one platform hosts both.
Do not use a flattened list of visible parts as the BOM. Hidden fasteners, packaging, services and non-rendered components may be required, while a visible subassembly may be sold as one line. Map from stable configuration IDs through an approved BOM or line rule set. Retain the mapping version and any exception that required human review.
For a representative product, reconcile four views side by side: resolved selections, visible product, priced commercial lines and operational BOM. Record expected quantities and intentionally omitted details. A mismatch should block the affected downstream action rather than be patched in the generated document.
Make the quote a governed transaction
Quote generation is a state transition, not a screenshot export. The transaction should point to the committed configuration, price response, account or buyer, terms, revision, owner, approval state and validity window. The rendered proposal is an output of that transaction.
Oracle’s transaction API documentation exposes distinct operations for creating and versioning transactions, generating proposals, publishing and accepting quotes, requesting revisions, submitting approvals and reconfiguring a transaction.[5] The operation names are specific to Oracle CPQ. They still show the lifecycle questions an implementation must answer instead of hiding every action behind a single “Generate PDF” button.
Use a quote snapshot that can be audited without reconstructing an old UI session. At minimum, retain:
- quote ID and revision;
- configuration ID and committed snapshot hash or immutable reference;
- catalog, rule, visual-map, pricing and BOM-map versions;
- price response ID, currency and effective context;
- buyer, seller, channel and market references;
- validity, approval and exception status; and
- generated document version and downstream handoff status.
If a quote is revised, record whether the configuration changed, the commercial context changed or only the document wording changed. Those cases require different review. Never overwrite the previous accepted snapshot merely to keep one convenient URL.
Specify enterprise integrations as contracts
Draw data ownership before drawing arrows. PIM or catalog services may own product identity and marketing content. A rule service may own validity. CPQ may own price and quote workflow. CRM may own account and opportunity context. ERP may own fulfillment structures or availability. The exact split is project-specific, but two systems should not quietly claim authority over the same field.
The OpenAPI Specification defines a language-agnostic description for HTTP APIs and says an OpenAPI Description formally describes an API’s surface and semantics.[6] Use that level of precision for configuration, price, BOM and quote boundaries: request and response schemas, identifiers, authentication, authorization, error states, timeouts, retries, idempotency, version policy and redacted examples.
Security review must follow the transaction, not stop at the public configurator. OWASP’s 2023 API Security Top 10 calls for object-level authorization checks when a function accesses data through a user-supplied ID. It also identifies object-property authorization, resource consumption, sensitive business-flow abuse and unsafe consumption of third-party APIs as separate risks.[7] Apply those concerns to saved configurations, customer-specific prices, quote revisions, proposal generation and privileged approvals. A hard-to-guess configuration ID is not an authorization policy.
Define retry behavior per operation. Reading a configuration, requesting a fresh price and submitting an approval do not have the same side effects. A network retry must not create duplicate quotes, approvals or orders. Use an idempotency strategy or deduplication key where a retried command could repeat a commercial action, and return a durable transaction reference to the caller.
Test the integrity chain with failure states
A demo path proves that components can cooperate once. Release evidence must show what happens when they disagree. Build test cases from the same representative configurations across rules, visuals, price, BOM, quote and downstream payloads.
| Test condition | Expected system decision | Evidence to retain |
|---|---|---|
| Candidate contains an excluded option pair | Rule layer rejects or repairs it with an explanation | Candidate, resolved result, rule version and reason code |
| Valid state maps to a missing asset | Commercial state remains explicit while preview follows the approved fallback or block policy | Configuration ID, asset-map version, missing ID and visible response |
| Pricing times out after a valid configuration | UI follows the named stale, pending, hidden or request-quote policy | Request ID, timeout, prior-price status and user message |
| BOM mapping cannot resolve a required component | Quote or order action is blocked for the affected state | Snapshot, mapping version, unresolved component and owner |
| Saved quote reopens under newer rules | System compares versions and requires review, migration or rejection | Old and new versions, decision and approver |
| User requests another party’s saved configuration | API denies access regardless of identifier validity | Test identity, object ID, denial and audit event |
| Downstream order payload loses an option | Reconciliation fails before acceptance | Quote revision, configuration reference, sent payload and expected line |
Run the matrix against named user roles and environments. Include a sales user, buyer or dealer path where relevant, approver, product administrator and integration identity. Test concurrent edits, expired quotes, withdrawn options, changed currencies, partial service outages and rollback. Keep sensitive customer and contract data out of reusable fixtures.
A pass means the recorded outputs agree for the stated versions and test profile. It does not prove every catalog family, region or integration. Expand coverage from real rule families and failure history rather than multiplying random combinations without knowing what they protect.
Organize delivery around ownership and evidence
Visual CPQ spans product, commercial and technical decisions. Name an owner for catalog IDs, rule families, visual mapping, pricing policy, BOM logic, quote workflow, integrations, security, testing and operation. If the same person owns several areas, keep the approvals distinct enough to expose conflicts.
The 3D product configuration services delivery guide covers the wider team, workstream and dependency plan. For this CPQ scope, each workstream should hand over inspectable artifacts: rule examples, API contracts, mapping tables, price fixtures, quote-state transitions, permission tests and a release matrix. A meeting or polished demo is not a substitute for those records.
The Spellexo case study documents Double Edged's ownership of the product strategy, UX, 3D production, engineering, testing, launch and ongoing operation.[9] It publishes no measured conversion or return-rate result and does not claim rescue or migration outcomes for an existing configurator.[9] A custom CPQ project still needs discovery around its own rules, price authority, outputs and systems.
Choose the implementation boundary from unresolved risk
A focused product with independent options, static public prices and a simple checkout may need a variant experience rather than full CPQ. A product with dependent rules, customer pricing, BOM output, approvals or governed quotes needs a stronger transaction and operating model. The decision should follow the integrity chain, not a preference for a particular viewer or platform.
Before implementation, ask for one representative product and trace it through all seven gates. If teams cannot name the authority, identifier, version and failure decision at a gate, that gap belongs in discovery. Do not cover it with a UI assumption.
When the unresolved work requires product-rule modeling, bespoke UX, real-time 3D, pricing and quote integration, the custom 3D product configurator service is the commercial route. Use the architecture above to document unresolved rules, price, quote and integration boundaries before starting that conversation.
