Connect NetSuite to Neblex CPQ

A quote gets approved in Neblex CPQ, and then somebody types it into NetSuite: the customer if it is new, the sales order, and for a configured product, the parts list manufacturing needs. Every rekeyed line is a chance to get a part number 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 finance whether it shipped.

Neblex CPQ does not ship a NetSuite 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 NetSuite connector with 271 operations, a polled trigger for changes in NetSuite, and the flow that maps one side to the other. CPQ stays focused on configuration, pricing, and approvals. Fabric owns the connection, the field map, the retries, and the run history.

The result: an approved quote becomes a NetSuite customer, a sales order, and an assembly item per configured line, on the schedule you set, with the NetSuite order number and status back on the quote.

Three parts: the Neblex CPQ API and event feed, the Fabric NetSuite 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 NetSuite side. The Fabric connector talks to NetSuite web services with credentials for an integration role; nothing is deployed into your NetSuite account. The quote-to-order flow uses upsertCustomer, createSalesOrder, upsertAssemblyItem, createWorkOrder, getSalesOrder, and suiteql, out of 271 operations. Changes in NetSuite reach the flow through one polled trigger, record_changed, which watches a SuiteQL last-modified timestamp on the record types you choose and fires 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 customer, pauses for a person where you ask it to, writes the NetSuite 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 control panel 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, 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 customer is resolved. upsertCustomer runs with the CPQ Customer id as the NetSuite external ID, companyName from name, and an address book entry from each CustomerAddress row. An existing customer is updated; a missing one is created.
5. 5A person checks the big ones. If totalPrice is above your threshold, or the customer is new, the flow pauses for an approval by email link. On reject, it stops and records the reason.
6. 6The bill of materials is built. For each configured line, upsertAssemblyItem runs with the line's partNumber as the item ID and one member per configBom row of type Component or Assembly, mapping partNumber and quantity. Rows with a parentLineNumber are written first as their own assembly items, so subassemblies keep their structure. Pricing rows in configBom are skipped; price is carried on the order line.
7. 7The sales order is created. createSalesOrder runs with the customer as the entity, quoteNumber as the other reference number, the quote currency, and one item line per QuoteLineItem with quantity and netPrice as the rate, so NetSuite does not reprice the quote. The external ID is the quote id plus revision, so a retry updates the same order. Optionally createWorkOrder runs for each assembly.
8. 8Status comes back. The flow writes the NetSuite 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 record_changed on sales orders and item fulfillments to update the quote as the order moves from pending fulfillment to billed.

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

Neblex CPQ to NetSuite

• Approved quotes become sales orders, one per approved quote revision
• Configured lines become assembly items, with an optional work order per assembly
• New and changed customers, from CUSTOMER_CREATED and CUSTOMER_UPDATED, are upserted
• Address changes, from CUSTOMER_ADDRESS_CREATED and CUSTOMER_ADDRESS_UPDATED, update the address book

NetSuite 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 record_changed on item fulfillments and invoices
• Customer master changes, when NetSuite 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 in one step.
• 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 customer.
• 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.