Skip to content

§00Connect

Salesforce ↔ Oracle NetSuite

Won in Salesforce. Ordered in NetSuite. Built on REST, not SOAP.

If your Salesforce–NetSuite integration runs on SuiteTalk SOAP, it has a deadline: NetSuite stops accepting new SOAP integrations with release 2027.1 and disables every SOAP endpoint with 2028.2. PartnerMCP builds the connection on NetSuite’s REST web services, SuiteQL and OAuth 2.0. A won Opportunity becomes a NetSuite customer and sales order; fulfillment, invoice and payment status come back to Salesforce — all within the concurrency limit your NetSuite account shares with every other integration.

Salesforce → NetSuite
Sandbox

You

“When an Opportunity is won in Salesforce, create the customer and sales order in NetSuite, then show fulfillment, invoice and payment status on the Opportunity.”

PartnerMCP· I will:

  1. Detect won Opportunities — IsWon = true — on Salesforce’s Change Data Capture stream.
  2. Upsert the customer in one call — PUT …/record/v1/customer/eid:<Account ID> creates it or updates it — and store NetSuite’s internal ID on the Account.
  3. Look for salesorder/eid:<Opportunity ID> first, then create the sales order: entity, the Opportunity ID as its external ID, and one item line per product with item, quantity and rate.
  4. Create the order pending approval, or pre-approved (orderStatus B) if finance agrees.
  5. Let NetSuite calculate tax with SuiteTax, and compare the order total with Opportunity.Amount.
  6. Follow fulfillment, invoicing and payment with SuiteQL on lastmodifieddate — or a SuiteScript afterSubmit script if you want push instead of polling.
  7. Write the sales order number and the fulfillment, invoice and payment status to the Opportunity.
  8. Stay inside the share of your account’s concurrency limit assigned to this integration, so your other integrations keep theirs.
Opportunity · Closed WonCustomer lookupSchema mappingCreate / update customerCreate sales orderMonitor orderSync fulfillmentWatch paymentUpdate Opportunity
Integration plan: Salesforce ↔ Oracle NetSuite. Salesforce to Oracle NetSuite.
  1. Opportunity · Closed Won — Salesforce: Trigger · Change Data Capture
  2. Customer lookup — PartnerMCP: Account ⇄ customer
  3. Schema mapping — PartnerMCP: fields · products · prices
  4. Create / update customer — NetSuite: customer
  5. Create sales order — NetSuite: salesorder + item sublist
  6. Monitor order — PartnerMCP: invoice · payment
  7. Sync fulfillment — NetSuite: itemfulfillment
  8. Watch payment — NetSuite: invoice → customerpayment
  9. Update Opportunity — Salesforce: payment status
Product preview · sample data
§01—What syncs

What syncs, and which way.

Every record that moves between Salesforce and NetSuite: what starts it, and what it produces on the other side.

SalesforceNetSuite
  1. Salesforce to Oracle NetSuite:

    Account → customer
    When
    First won Opportunity for the account
    Result
    Customer upserted by external ID (eid:); NetSuite’s internal ID stored on the Account.
  2. Salesforce to Oracle NetSuite:

    Opportunity → salesorder
    When
    OpportunityChangeEvent with IsWon = true — or an Order whose StatusCode becomes Activated
    Result
    Sales order created Pending Approval by default, or Pending Fulfillment when pre-approved.
  3. Oracle NetSuite to Salesforce:

    inventoryitem → Product2
    When
    Item changes found with SuiteQL
    Result
    Salesforce products mirror NetSuite items, so every Opportunity line resolves to an item.
  4. Oracle NetSuite to Salesforce:

    itemfulfillment → Opportunity
    When
    SuiteQL on lastmodifieddate, or a SuiteScript afterSubmit call
    Result
    Fulfillment status and date on the Opportunity.
  5. Oracle NetSuite to Salesforce:

    invoice → Opportunity
    When
    Invoice created from the sales order
    Result
    Invoice number and status on the Opportunity.
  6. Oracle NetSuite to Salesforce:

    customerpayment → Opportunity
    When
    Payment applied to the order’s invoice
    Result
    Paid status and payment date on the Opportunity.
§02—Field mapping

Field by field.

Every mapping PartnerMCP proposes, with its transformation and confidence. Rules — keys, reconciliation, duplicate guards — carry no confidence: they’re decided and approved, not inferred.

Salesforce ⇄ NetSuite
Draft
  1. Account.Id

    to customer · eid:<Account.Id>

    External ID in the URL; PUT creates or updates

    97% confidence
    One idempotent call, so a retry can’t create a second customer.
  2. Account.Name

    to customer.companyName

    Trimmed to the field’s length

    97% confidence
  3. customer · internal ID

    to Account.NetSuite_Customer_Id__c

    Written back after the upsert

    95% confidence
  4. Rule table · account region

    to customer.subsidiary

    Where your account has subsidiaries

    Rule
    Chosen by a rule you approve, never guessed per record.
  5. Opportunity.AccountId

    to salesorder.entity

    The customer’s internal ID

    97% confidence
    NetSuite fills many order fields from the entity.
  6. Opportunity.Id

    to salesorder · eid:<Opportunity.Id>

    Looked up before every create

    Rule
    Synchronous REST creates have no idempotency key, so the external ID is the duplicate guard.
  7. OpportunityLineItem.ProductCode

    to item.items[].item

    Resolved to the item’s internal ID with SuiteQL

    93% confidence
  8. OpportunityLineItem.Quantity

    to item.items[].quantity

    Copied as-is

    97% confidence
  9. OpportunityLineItem.UnitPrice

    to item.items[].rate

    Or amount, if you send line totals

    86% confidence
    From 2026.1, NetSuite recalculates amount when a taxable line is sent with grossAmt.
  10. Opportunity.CloseDate

    to salesorder.tranDate

    Or left blank, which NetSuite treats as today

    85% confidence
  11. Opportunity.Amount

    to Sales order total — reconciled, not written

    Compared after SuiteTax calculates tax

    Rule
8 field mappings · 3 rules Confidence Lower, or verify on tenant
Product preview · sample data
§03—Edge cases

Edge cases, handled.

What goes wrong between Salesforce and NetSuite in production, and what PartnerMCP does about it.

  1. 01

    SOAP has an end date

    NetSuite’s 2025.2 SOAP endpoint is the last one. From 2027.1 no new SOAP integrations can be built — nor new ones on token-based authentication — and with 2028.2 all SOAP endpoints are disabled. PartnerMCP uses REST web services, SuiteQL and OAuth 2.0 only.

  2. 02

    Legacy tax doesn’t work over REST

    REST web services don’t support NetSuite’s legacy tax features; tax over REST needs SuiteTax. PartnerMCP checks this during discovery, and an account still on legacy tax gets the options up front — moving to SuiteTax, or a RESTlet for the tax fields — instead of a surprise in production.

  3. 03

    Retries without duplicates

    Synchronous REST creates have no idempotency key, and X-NetSuite-idempotency-key only covers asynchronous requests. PartnerMCP addresses customers and orders by external ID (eid:), so a retried request finds the record instead of creating another.

  4. 04

    Opportunity or Order?

    Some teams close Opportunities; others activate Salesforce Orders. PartnerMCP can trigger on either — an Opportunity whose IsWon turns true, or an Order whose StatusCode becomes Activated — with the same duplicate check for both.

  5. 05

    Pending Approval by default

    A sales order created over REST starts as Pending Approval (orderStatus A) and moves to Pending Fulfillment (B) once approved. PartnerMCP creates orders pending approval unless finance wants them pre-approved, and the plan says which.

  6. 06

    One concurrency pool

    NetSuite caps concurrent requests per account — 5 on Standard, 15 on Premium, 20 on Enterprise and Ultimate, plus 10 per SuiteCloud Plus license — and REST, RESTlets, SOAP and the AI Connector Service all draw on it. PartnerMCP runs within the allocation you give its integration record.

  7. 07

    The form decides what billing creates

    A sales order’s customForm decides whether billing produces an invoice or a cash sale. PartnerMCP sets the form deliberately and follows whichever record billing creates, so the Opportunity shows the right document.

§04—Questions

Questions about Salesforce and NetSuite.

Can PartnerMCP use NetSuite’s AI Connector Service?

Where it fits. The AI Connector Service is NetSuite’s MCP endpoint: it creates and updates records and runs reports and saved searches, its SuiteQL tools are read-only, it doesn’t accept the Administrator role and it draws on the same concurrency pool. PartnerMCP runs the order flow on REST web services and can use the AI Connector for conversational questions.

We already have a SOAP integration. What happens to it?

It keeps working until NetSuite 2028.2 disables SOAP endpoints. Give PartnerMCP the current mappings and a sandbox, and it rebuilds the flow on REST and OAuth 2.0 and runs old and new side by side in the sandbox before you switch.

Which NetSuite authentication does it use?

OAuth 2.0 — the machine-to-machine client credentials flow with a certificate, for server-to-server work. Token-based authentication isn’t used: from 2027.1, NetSuite won’t accept new integrations built on it.

What does it need on the Salesforce side?

An External Client App for OAuth — new Connected Apps are disabled by default since Spring ’26 — and Change Data Capture on Opportunity. CDC counts against your org’s selected entities (five by default) and its daily event-delivery allocation, which PartnerMCP plans for.

Which NetSuite records does it touch?

It writes customers and sales orders, and reads items, fulfillments, invoices and customer payments — through a dedicated role limited to those records.

§05—References

§06Build

Build this integration.

Start from this plan, or change it in your own words. PartnerMCP builds it against your Salesforce and NetSuite: sandbox first, production when you approve.