Start with a data-ownership map
Before drawing any arrows, decide which system is the source of truth for each type of data. A typical split has Salesforce owning leads, opportunities, quotes, and contacts, and NetSuite owning items, prices, inventory, invoices, and payments. Customers are the interesting case: they often originate in Salesforce but become financial records in NetSuite, so you need rules for creation, matching, and updates.
- Write the map as a table: record type, owning system, and who may edit.
- Pick a unique identifier to link records across systems, and store it in both.
- Decide what happens when the two systems disagree.
The lead-to-cash flow
The most common flow runs from a closed-won opportunity to a customer, sales order, and invoice. When an opportunity closes, the integration checks whether the customer exists in NetSuite, creates or links it, and creates a sales order with the agreed products and prices. Fulfillment and invoicing happen in NetSuite, and status, invoice numbers, and payment information return to Salesforce for the account team to see.
Keep the first version simple. A reliable flow for the most common order type is worth more than a clever one that handles every exception badly.
Products, prices and quotes
Product and price data must be consistent or quotes will not match invoices. The usual pattern is for NetSuite to hold the item master and base prices, with a scheduled sync to Salesforce price books. If quoting involves discounts and approvals in Salesforce, the final negotiated price travels to NetSuite with the order, and NetSuite accepts it instead of recalculating.
Revenue and pricing solutions →Choosing how to connect: native connector, middleware or custom
Options range from prebuilt connectors, through integration platforms that provide mapping and monitoring tools, to custom-coded interfaces. Prebuilt connectors are fast to start but may not fit unusual processes. Integration platforms offer visibility and reuse across several systems, at the cost of another subscription and skill set. Custom code gives the most control and the most maintenance. Choose based on how standard your processes are, how many systems you will connect, and who will support it.
Error handling, monitoring and reconciliation
Integrations fail: a required field is missing, a customer is duplicated, a connection times out. Design for it. Failed records should land in a queue where a named person can see the reason, fix the data, and retry. Send alerts for failures above a threshold, and run a regular reconciliation that compares counts and totals between systems, such as the number of closed deals against orders created.
Implementation and integration services →Decisions to settle before you build
- Customer matching rule. Choose how to decide that a Salesforce account and a NetSuite customer are the same, such as a shared identifier or a verified tax number.
- Sync direction and timing. Decide which flows are real-time and which are scheduled, and the acceptable delay.
- Handling of changes. Define what happens when an order is amended or canceled after it has been sent.
- Ownership of support. Name the team that responds when the integration fails.
A realistic first 90 days
- Days 1 to 30. Create the data-ownership map, agree identifiers and matching rules, and select the connection approach.
- Days 31 to 60. Build and test the customer, product, and order flows with realistic data and edge cases.
- Days 61 to 90. Add status return, error queues, and reconciliation, then go live with the most common order type before widening scope.
Pitfalls to avoid
- Two masters for the same field. If both systems can edit a field, one will overwrite the other. Assign a single owner.
- No unique identifier. Matching on names creates duplicates. Store a shared key on both sides.
- Ignoring limits. Each system restricts how many calls and records it processes. Design for volume and test at peak load.
- No monitoring. An integration nobody watches will fail quietly until a customer notices.
