Configurix
Implementation series

Phase 4: Quotes, BOM, Integrations and Product Configurator Testing

Connect one accepted configuration to quotes, CRM, ERP, ecommerce or BOM outputs, then prove the complete workflow with structured acceptance and failure tests.

Configurix Team9 min read
Configured product connected to a branded proposal, CRM project record, bill of materials and testing checklist
Table of contents
  1. Begin with the saved configuration record
  2. Generate branded quotes from structured state
  3. Distinguish option summary, order data and BOM
  4. Define every integration as a contract
  5. CRM integration: preserve buying context
  6. ERP and order integration: prove acceptance at the destination
  7. E-commerce integration: preserve configuration identity
  8. Design for retries and duplicate prevention
  9. Protect data and business flows
  10. Build a product configurator test model
  11. Catalogue and identity tests
  12. Rule and dimension tests
  13. 3D tests
  14. Pricing tests
  15. Quote and document tests
  16. BOM and order tests
  17. Integration tests
  18. Accessibility and performance tests
  19. Use a traceable acceptance pack
  20. How Configurix approaches phase 4
  21. Common phase-4 mistakes
  22. Testing only the happy path
  23. Comparing totals but not calculation traces
  24. Treating document appearance as document accuracy
  25. Calling an API request an integration
  26. Calling every component list a production BOM
  27. Phase 4 completion checklist
  28. Frequently asked questions
  29. Can Configurix generate branded PDF quotes?
  30. Can Configurix generate a bill of materials?
  31. Can Configurix integrate with our CRM or ERP?
  32. Who tests the configurator?

Phase 4 turns a configured product into a reliable business transaction. The same accepted configuration may need to create a branded quote, structured lead, CRM opportunity, e-commerce cart, dealer order, ERP payload, bill of materials or production handoff.

This is where attractive demonstrations become operational software. Every output must preserve the product, revision, dimensions, options, commercial context and ownership defined in the earlier phases.

Implementation series: Phase 1 — discovery and requirements · Phase 2 — product data, rules and pricing · Phase 3 — 3D assets and UX · Phase 4 — integrations and testing · Phase 5 — launch and optimization

Begin with the saved configuration record

Before generating documents or sending data, define the project record that represents the decision. It commonly contains:

  • configuration and revision ID;
  • product family, model and market;
  • dimensions, units and derived values;
  • selected options and accepted rule version;
  • price list, currency, tax, discount and total;
  • customer and account context;
  • visual snapshot or camera reference;
  • creation, update and approval timestamps;
  • owner, channel and workflow status;
  • source and destination identifiers.

The record should be reproducible. Reopening a project should not silently apply current options or prices when the accepted policy requires the historical revision.

Generate branded quotes from structured state

A useful quote is not a screenshot with a total. It should explain what is being offered and remain connected to the configuration that produced it.

A quote may include:

  • customer and seller details;
  • quote number, revision, date and validity;
  • product name and configured image;
  • dimensions and option summary;
  • itemized or grouped price lines;
  • installation, delivery, tax and discount information;
  • exclusions, assumptions and next steps;
  • approval or signature action;
  • links back to the saved project or customer portal.

Configurix can generate branded quote documents when included in the workflow. The document structure, legal wording, price presentation, languages and approval behavior are customized to the business and market.

Quote revisions need policy. Decide whether a changed configuration creates a new quote revision, invalidates an earlier approval or preserves both versions for audit.

Distinguish option summary, order data and BOM

“BOM” is often used for several different outputs:

  • customer option summary — what the buyer selected;
  • sales BOM — commercial components or packages;
  • configured order structure — accepted lines for order entry;
  • installation pack — components, drawings and site information for a crew;
  • manufacturing BOM — production-authorized parts and quantities;
  • cut-list or machine input — derived dimensions and instructions for fabrication.

These outputs have different owners, units, revisions and acceptance requirements. Do not label an option list as production-ready.

When BOM generation is scoped, the model may need:

  • component and variant IDs;
  • quantities and units;
  • dimension formulas and rounding;
  • hierarchy and parent-child relationships;
  • substitutions and effectivity;
  • hardware, consumables and packaging rules;
  • revision and approval status;
  • destination field mapping.

The configurator BOM generation guide explains these distinctions and validation methods.

Define every integration as a contract

An integration is more than a destination logo. Document:

  • source and destination;
  • business owner and technical owner;
  • trigger and preconditions;
  • authentication and authorization;
  • stable identifiers and correlation ID;
  • required and optional fields;
  • schema and version;
  • response and acknowledgement;
  • timeout and retry behavior;
  • duplicate prevention;
  • error visibility and reconciliation;
  • monitoring and deprecation.

A CRM lead, ERP order and production BOM are different contracts. Implement and accept one complete lifecycle at a time.

The product configurator integrations guide provides a framework for CRM, ERP, PIM, e-commerce, pricing, document, analytics and webhook connections.

CRM integration: preserve buying context

A generic form usually captures name, email and message. A configured lead can also include:

  • product and model;
  • dimensions and selected options;
  • price context or budget;
  • saved project and revision;
  • visual snapshot;
  • market, language, dealer or territory;
  • engagement and completion event;
  • consent and attribution data where appropriate.

Decide which fields belong in the CRM, which remain in Configurix and how a salesperson reopens the project. Avoid dumping every low-level configuration property into an unreadable note.

Configurix can connect structured product enquiries, project context and follow-up into a CRM workflow when scoped. Read the configurator CRM integration guide.

ERP and order integration: prove acceptance at the destination

An API request returning success does not prove that an ERP created the intended order. Test the destination result:

  • correct customer or account;
  • accepted product and component IDs;
  • dimensions, quantities and units;
  • price, tax and currency;
  • delivery and installation context;
  • revision and source configuration ID;
  • status and acknowledgement.

ERP integrations may create a quotation, sales order, configured material, project or another object depending on the business. Use the configurator ERP integration guide to define authority and handoff boundaries.

E-commerce integration: preserve configuration identity

A configurable product placed in a cart needs more than a display name. Store a reference to the accepted configuration, revision and price context. Define what happens when the shopper returns later and the catalogue or price has changed.

The cart should not permit quantity or option changes that bypass configuration rules. If the product needs technical review before purchase, the completion action may be a quote or reservation rather than immediate checkout.

Design for retries and duplicate prevention

Network failures happen after an action reaches the destination as well as before it leaves the source. Retrying without a correlation or idempotency strategy can create duplicate leads, orders or payments.

HTTP defines an idempotent method as one where multiple identical requests have the same intended server effect as a single request (RFC 9110). Business APIs often need an additional idempotency or correlation key even when using POST.

For every write operation, test:

  • timeout before destination receipt;
  • timeout after destination creation;
  • duplicate retry;
  • partial processing;
  • invalid field or mapping;
  • authentication expiry;
  • destination outage;
  • delayed acknowledgement;
  • manual replay and reconciliation.

Protect data and business flows

Configurator integrations may handle customer details, account prices, product logic and order data. Security requirements should include least-privilege access, authorization checks, input validation, secret management, transport protection, rate limits, logging and retention.

The OWASP API Security project highlights risks including broken object-level authorization, broken authentication, unrestricted resource consumption and unsafe consumption of APIs (OWASP API Security Top 10). Use that guidance as part of risk review; it does not replace a system-specific threat model.

The configurator security and privacy guide covers roles, tenant boundaries, personal data, APIs, logs, retention and vendor evaluation.

Build a product configurator test model

Testing should trace user action to structured state and downstream consequence. Organize coverage by domain.

Catalogue and identity tests

  • correct product, market and revision load;
  • stable IDs survive label and translation changes;
  • unavailable products cannot be reopened as current without policy.

Rule and dimension tests

  • required, excluded and dependent options;
  • minimum, maximum and breakpoint dimensions;
  • repeated changes and conflict resolution;
  • invalid saved or API-submitted state.

3D tests

  • visual component and material match configuration IDs;
  • scale, pivots, camera, clipping and transparency;
  • normal and largest valid scenes;
  • saved state reopens with the same appearance.

Pricing tests

  • expected subtotal and line trace;
  • formulas, matrices and rounding;
  • price list, account, market, tax and discount permissions;
  • historical quote behavior after price changes.

Quote and document tests

  • product, dimensions, options, image and price match the project;
  • revision, language and market wording are correct;
  • document generation failure is visible and recoverable.

BOM and order tests

  • component IDs, quantities, units and dimensions;
  • dependencies, substitutions and hierarchy;
  • accepted destination result and acknowledgement.

Integration tests

  • authentication, authorization and schema validation;
  • idempotency, retries, duplicates and ordering;
  • timeout, partial failure, outage and reconciliation;
  • monitoring and support ownership.

Accessibility and performance tests

  • keyboard, focus, labels, errors and structured alternatives;
  • useful loading, interaction response and layout stability;
  • supported devices, browsers, networks and largest scenes.

The complete product configurator testing and QA guide includes detailed fixtures and release evidence.

Use a traceable acceptance pack

Each acceptance case should record:

  • fixture or configuration ID;
  • preconditions and role;
  • steps or input payload;
  • expected structured state;
  • expected visual result;
  • expected price and calculation trace;
  • expected quote, BOM or integration output;
  • destination evidence;
  • reviewer, date and result;
  • defect or approved exception.

Screenshots help with visual review but cannot prove product IDs, formula provenance, BOM quantity or API behavior.

How Configurix approaches phase 4

Configurix can connect one saved configuration to:

  • branded quotes and project documents;
  • structured customer enquiries and sales follow-up;
  • CRM project or opportunity context;
  • e-commerce or dealer ordering journeys;
  • optional BOM, configured-order or production handoff;
  • ERP, PIM, pricing, scheduling, API and webhook integrations;
  • customer portals and revision workflows.

The exact outputs and integrations are implementation-specific. Configurix does not claim that every 3D model automatically becomes a production BOM or that every system connection is included by default. Component mappings, field contracts, permissions, failure behavior and acceptance evidence are part of the scope.

Common phase-4 mistakes

Testing only the happy path

Failures, retries and duplicates are part of the workflow, not edge cases to postpone.

Comparing totals but not calculation traces

Two equal totals can contain different taxes, options or rounding. Verify the lines and provenance.

Treating document appearance as document accuracy

Brand polish matters, but product, revision, price, terms and customer context must also be correct.

Calling an API request an integration

An integration includes destination state, reconciliation, monitoring and ownership.

Calling every component list a production BOM

Use the exact operational term and acceptance authority.

Phase 4 completion checklist

Phase 4 is complete when:

  • saved projects preserve accepted configuration and revision identity;
  • branded documents match product, price and market context;
  • optional BOM or order outputs are mapped and reconciled where scoped;
  • each integration has an owner, contract, error path and monitoring plan;
  • retries do not create uncontrolled duplicates;
  • security and privacy controls are reviewed;
  • normal, boundary, invalid and failure cases pass;
  • business owners approve destination evidence, not only source screenshots;
  • release blockers and accepted exceptions are documented.

The final implementation phase publishes the accepted system and establishes measurement, support and change governance. Continue with Phase 5: Product Configurator Launch, Analytics and Continuous Improvement.

Frequently asked questions

Can Configurix generate branded PDF quotes?

Yes. Configurix can generate branded quotes and project documents using the accepted configuration and commercial context. Templates, languages, legal wording, line detail and approval actions are customized to the implementation.

Can Configurix generate a bill of materials?

Yes, when BOM generation is scoped and the product model contains the required component mappings, quantities, units, dimensions and revisions. The output must be tested against the intended operational authority.

Can Configurix integrate with our CRM or ERP?

Configurix can integrate with CRM, ERP, PIM, e-commerce and other systems through scoped APIs, webhooks or data contracts. Feasibility depends on the destination system, permissions, available interfaces and accepted lifecycle.

Who tests the configurator?

Testing is shared. Configurix can implement and verify the software, while product, price, document, integration and operational owners approve the business truth in their domains. One accountable owner coordinates release acceptance.

Ready to try Configurix?

See how the configurator, quoting and CRM work together for your business.

Book a demo →

Related articles