Connect Salesforce to Neblex CPQ

Reps live in Salesforce. Product rules, price lists, and the approval matrix live in Neblex CPQ. Without a link, a rep copies the account, contact, and opportunity into the quoting tool by hand, then copies the quote number and total back. Every customer ends up spelled two ways, the opportunity amount lags the quote by days, and the forecast is built on whichever number was typed last.

Neblex CPQ has no Salesforce connector of its own, by design. It exposes every customer and quote operation through its API and records every meaningful change in a pull-based event feed that the consumer fetches and acknowledges. Neblex Integration Fabric supplies the other half: a Salesforce connector with 1,296 operations and 95 polled triggers, and a visual flow between the two that maps fields, matches records, pauses for a person when a decision needs one, and writes the result back.

The split of ownership is the point. Salesforce owns the account and the opportunity. CPQ owns the configuration, the price, the approval, and the quote record. Neither side edits what the other owns.

On the CPQ side there are two surfaces. The first is the API, reached through the Neblex CPQ connector in Integration Fabric, which carries 286 operations. This flow uses postapi_customers_list to find an existing customer, postapi_customers, postapi_customer_addresses, and postapi_customer_contacts to create one, postapi_quotes for the quote header, putapi_quotes_id for the line items, and getapi_quotes_id to read the total. Every call clears the four mandatory access layers and the token's per-module scopes before any business logic runs.

The second surface is the event feed. An event listener subscribes a service account to the event types the flow needs: QUOTE_CREATED, QUOTE_STATUS_CHANGED, and QUOTE_VERSION_CREATED, which are append-only, one ordered row per occurrence, and QUOTE_UPDATED, which is coalesced to the latest state of the quote. CPQ offers no push webhooks. The flow fetches with postapi_integrations_listeners_id_events_fetch on the schedule you set, processes the batch, and acknowledges it with postapi_integrations_listeners_id_events_ack.

On the Salesforce side, the Integration Fabric connector authenticates with OAuth 2.0 and respects the connected user's field-level and object permissions. The flow starts from the changed_list_Opportunity trigger, which is polled on the schedule you set. It reads with get_Opportunity, get_Account, and query, and writes back with update_Opportunity. None of the 95 Salesforce triggers deliver webhooks; if your org can send outbound messages to an HTTPS address, point them at a Neblex webhook endpoint for an event-driven start.

Between them sits the flow: mapping, matching, an optional approval, and a run log.

Triggered on the stage change, matched on the opportunity ID, safe to run twice.

1. 1Trigger. The polled changed_list_Opportunity trigger fires when Opportunity.StageName reaches the stage you pick, for example Proposal/Price Quote. The flow reads the opportunity with get_Opportunity, its account with get_Account, and the primary contact through query.
2. 2Idempotency. If Opportunity.Neblex_Quote_Id__c is already populated, the quote exists and the run stops, so a re-fired trigger is harmless.
3. 3Resolve the customer. postapi_customers_list searches CPQ for a customer whose customerNumber equals Account.Id. If none is found, postapi_customers creates the customer, postapi_customer_addresses creates a BILL_TO and a SHIP_TO address from the account's billing and shipping fields, and postapi_customer_contacts creates the contact. CPQ records CUSTOMER_CREATED in the feed.
4. 4Create the quote. postapi_quotes creates the quote header with quoteName from the opportunity name, currency from the opportunity currency, validUntil from the close date, and the custCustomerId, custContactId, and custBillToId references from step 3. The opportunity ID is stored in customFieldValues. Then putapi_quotes_id writes one line per OpportunityLineItem, keyed on the product code as partNumber. CPQ records QUOTE_CREATED.
5. 5Write the number back. update_Opportunity sets Neblex_Quote_Id__c and Neblex_Quote_Number__c, so the rep can open the quote from the opportunity.
6. 6The rep works the quote in CPQ. Configurable products are built in the product configurator, pricing rules apply, and a discount past your threshold moves the quote to Needs Approval and locks it until an approver acts. Each stage move records QUOTE_STATUS_CHANGED with fromStatus and toStatus.
7. 7Status back. When the polled fetch returns a QUOTE_STATUS_CHANGED event, the flow reads the quote with getapi_quotes_id, then update_Opportunity sets Neblex_Quote_Status__c to toStatus and Amount to totalPrice. When toStatus is your closed-won snapshot status, the flow can also set StageName to Closed Won. It then acknowledges the event by lastEventId.
8. 8Optional gate. If the quote total is over a threshold you set, the flow pauses for a named approver in Integration Fabric before it touches the opportunity stage. On reject, it logs a note on the opportunity and stops.

The starting map for the opportunity to quote step. Every CPQ field named here exists on the customer, address, contact, quote, or line item record.

Salesforce to Neblex CPQ

• Customers. Account name, website, industry, and a stable customer number, created once and matched on later runs.
• Addresses and contacts. Billing and shipping addresses as BILL_TO and SHIP_TO, and the primary contact.
• Quote header. Name, currency, validity date, and the customer, contact, and bill-to references.
• Line items. Standard products from the opportunity's line items, keyed on part number.

Neblex CPQ to Salesforce

• Quote identity. The CPQ quote ID and quote number, written to the opportunity on creation.
• Status. Every stage move, from QUOTE_STATUS_CHANGED, including the closed-won snapshot status.
• Amount. The quote total, read after each status event, so the forecast follows the priced quote.

• Service account scopes. The flow authenticates to CPQ as a service account, not a user. Its token starts with every action disabled on every module, and an administrator enables only read, create, and update on the customer and quote modules. Disabling the account revokes every token beneath it in one step.
• Four layers on every call. Environment header, client certificate, bearer token, and the optional IP allowance, checked in that order, before scopes are evaluated.
• Event acknowledgment. Events are delivered at least once until the flow acknowledges them, so a run that fails mid-batch sees the same events again, and the cursor never regresses. A coalesced QUOTE_UPDATED record that changed between fetch and acknowledgment is marked stale and arrives again on the next fetch.
• Approvals in the flow. Discount and margin approvals run inside CPQ, where the quote locks and cannot be unlocked by anyone until an approver acts. Thresholds that concern the CRM, such as a large deal stage change, pause in Integration Fabric for a named approver.
• Run history. Every run records the opportunity, the customer it resolved, the lines it mapped, and each CPQ and Salesforce response, and can be replayed from the step that failed without re-creating the quote.
• Audit log. CPQ writes an audit entry for every create and update the service account makes, under the service account's name. Each token records when it was last used, so a dormant credential is easy to find and revoke.