Connect Microsoft Dynamics 365 to Neblex CPQ

A quote gets approved in Neblex CPQ, and then somebody rebuilds it in Dynamics 365: the account if it is new, the sales order and each of its lines, and for a configured product, the parts list operations needs. Every rekeyed line is a chance to get a product or quantity wrong, and every hour before order entry is an hour the customer waits. Once the order exists, the quote and the order drift apart, and sales has to ask whether it was fulfilled or invoiced.

Neblex CPQ does not ship a Dynamics 365 connector of its own, and it does not push webhooks. It publishes an ordered event feed that an outside system pulls and acknowledges, and it exposes an API for reading quotes, line items, bills of materials, and customers. Neblex Integration Fabric supplies the other half: a Dynamics 365 connector with 160 operations, seven polled triggers for changes in Dynamics, and the flow that maps one side to the other. Fabric owns the connection, the field map, the retries, and the run history.

The result: an approved quote becomes a Dynamics 365 account, a sales order with lines, and bill of materials rows per configured line, on the schedule you set, with the order number and status back on the quote.

Three parts: the Neblex CPQ API and event feed, the Fabric Dynamics 365 connector, and a flow in between.

On the Neblex CPQ side. You create a service account in your environment, issue it a service token, and enable only the scopes the flow needs: read and update on the QUOTE module, read on the CUSTOMER module. An event listener on that service account subscribes to the event types the flow needs: QUOTE_STATUS_CHANGED, QUOTE_APPROVED, QUOTE_VERSION_CREATED, CUSTOMER_CREATED, CUSTOMER_UPDATED, and CUSTOMER_ADDRESS_UPDATED. The listener's fetch endpoint returns ordered stream events and coalesced pending events, which hold only the latest state of a record edited several times. The flow acknowledges what it processed, and an event is delivered at least once until it is acknowledged.

On the Dynamics 365 side. The Fabric connector signs in with OAuth 2.0 to the Dynamics 365 web API and works with standard and custom tables. The quote-to-order flow uses upsertRow, createOrder, createOrderLine, updateOrder, createRow, getOrder, and searchQuery, out of 160 operations. Changes in Dynamics reach the flow through polled triggers: account_changed, contact_changed, opportunity_changed, row_created, row_updated, lead_created, and case_created, firing on the schedule you set. The connector's operations do not carry typed output schemas, so the field map is configured in the flow rather than pre-verified.

The flow in between. A Fabric flow polls the CPQ listener, keeps the events it wants, reads the full quote through the API, resolves the account, pauses for a person where you ask it to, writes the Dynamics records, writes the order number back to the quote, and acknowledges the events. Matt, the Neblex AI Assistant, can explain which CPQ fields and events to use; Matt only advises and never builds or runs a flow.

The product is a configured conveyor section with a bill of materials produced by CPQ rules.

1. 1The quote is approved. It moves to the stage you treat as approved, and CPQ writes a QUOTE_STATUS_CHANGED event to the listener's queue with quoteId, quoteNumber, fromStatus, toStatus, and updatedAt.
2. 2The flow polls. On the schedule you set, typically every 10 to 60 seconds, it calls the fetch endpoint, reads the stream events in order, and keeps those whose toStatus is your approved stage.
3. 3The flow reads the quote. GET /api/quotes/{id} returns the header (quoteNumber, quoteName, revision, currency, totalPrice, custCustomerId, custBillToId, custShipToId) and the line items. GET /api/quotes/{id}/hydrate returns the linked customer, addresses, and terms. For every line where isConfigured is true, GET /api/quotes/{id}/line-items/{lineItemId}/bom returns the configBom rows.
4. 4The account is resolved. upsertRow runs on the account table, keyed on a column you add to hold the CPQ Customer id, with name, website, and the BILL_TO CustomerAddress as the primary address. An existing account is updated; a missing one is created.
5. 5A person checks the big ones. If totalPrice is above your threshold, or the account is new, the flow pauses for an approval by email link. On reject, it stops and records the reason.
6. 6The sales order and its lines are created. createOrder runs with the account as the customer, quoteName as the order name, and the quote currency, then createOrderLine runs once per QuoteLineItem. A line whose partNumber matches a Dynamics product references it; any other line is a write-in product with the CPQ description. Each line carries quantity and netPrice as the price per unit, marked as an override so Dynamics does not reprice.
7. 7The bill of materials is written. For each configured line, createRow runs once per configBom row of type Component or Assembly, into the table your Dynamics environment uses for bills of materials, carrying partNumber, quantity, lineNumber, and parentLineNumber so the indented structure survives. Pricing rows in configBom are skipped; price is carried on the order line.
8. 8Status comes back. The flow writes the Dynamics order number to a custom field on the quote with PUT /api/quotes/{id}, or advances the quote to an ordered stage with PATCH /api/quotes/{id}/stage, then acknowledges the events. A second flow uses row_updated on the sales order table to update the quote as it moves to fulfilled or invoiced.

The starting map for the quote-to-sales-order step. It is configured in the flow, so every field, including custom columns, can be changed.

Neblex CPQ to Dynamics 365

• Approved quotes become sales orders with lines, one per approved quote revision
• Configured lines become bill of materials rows in the table you choose
• New and changed customers, from CUSTOMER_CREATED and CUSTOMER_UPDATED, are upserted as accounts
• Address changes, from CUSTOMER_ADDRESS_CREATED and CUSTOMER_ADDRESS_UPDATED, update the account address

Dynamics 365 to Neblex CPQ

• The sales order number and status, written to a custom field on the quote or reflected as a stage change
• Fulfillment and invoice status, from row_updated on the sales order and invoice tables
• Account changes, from account_changed when Dynamics is the system of record, written with PUT /api/customers

• Scoped service account. The flow authenticates as a named service account, not a person. Its token starts with every scope off, and you enable only what the flow uses. Disabling the account revokes its tokens.
• Certificate and network checks. Every call presents a client certificate issued from your settings, and you can refuse calls from any source IP not on your approved list.
• Event acknowledgment. Events stay queued until acknowledged, so a crash mid-batch means a replay, not a lost order. Coalesced events carry a version, and a stale acknowledgment is rejected.
• Approvals in the flow. Any step can pause for a person: orders above a value, or first orders for a new account.
• Run history. Every run is a step-by-step record with input and output. A failed run stops at the failed step and can be replayed from there.
• Audit log. Service account calls appear in the CPQ audit log under the account's name, and each token shows a last-used timestamp.