Which objects move, in which direction, on what cadence — and which system wins when both change the same record. Twopir Consulting designs, configures and operates record-level sync between Salesforce and NetSuite, with externalId-keyed dedup, signed conflict rules, and error queues someone actually reads. The CRM and the ERP, finally telling the same story.
Trusted by 500+ organizations — including operations and finance teams running Salesforce alongside NetSuite and other ERPs with Twopir Consulting.
Built for CRM–ERP Reliability
A broken sync rarely announces itself. It shows up as a rep quoting a customer finance put on credit hold, a duplicate invoice, or a month-end close that doesn't reconcile. Six failure patterns account for most of it.
When flows match records by name or email instead of a shared externalId, every retry and every edge case creates a new record instead of updating the existing one. Duplicate customers in NetSuite mean duplicate invoices — and finance stops trusting the sync.
"Bi-directional" built as two independent one-way flows, with no conflict rules between them, produces overwrite loops: sales updates an address in Salesforce, the ERP flow writes the old value back an hour later, and nobody can say which version is right.
A record fails validation, the flow skips it, and no error queue or alert exists. The gap surfaces weeks later as a deal closed in Salesforce with no sales order in NetSuite — the canonical silo symptom an integration was supposed to eliminate.
Salesforce and NetSuite differ in field names, data types, picklist values and currency decimal precision. Each unmapped custom field, renamed picklist value or precision mismatch added after go-live is a future sync error nobody planned for.
NetSuite governs one account-level concurrency pool shared by all web services and RESTlet requests. An end-of-quarter order surge exceeds it, requests return HTTP 429 with SSS_REQUEST_LIMIT_EXCEEDED, and a sync built without throttling and retries drops exactly the records that matter most.
In multi-subsidiary NetSuite OneWorld, the same company legitimately exists as separate customer records under different subsidiaries. A sync that matches on email alone either creates duplicates or writes one subsidiary's data over another's.
Salesforce–NetSuite data sync is the automated, rule-governed exchange of records between Salesforce, the CRM, and NetSuite, the ERP: which objects move, in which direction, on what cadence, which system is the system of record for each field, and what happens when the two disagree. Done well, sales, finance and operations read the same customer, order and invoice data in whichever system they work.
The platforms supply the raw capability. NetSuite exposes SuiteTalk REST web services, SuiteQL and RESTlets; Salesforce provides its REST, Bulk and platform-event APIs; and tools like Celigo integrator.io, MuleSoft Composer, Breadwinner and Oracle's NetSuite Connector for Salesforce package the plumbing. What none of them decide for you is the operating policy — ownership, dedup keys, conflict rules, cadence and error handling. That policy is what Twopir designs, configures and enforces.
We build this discipline for growing and mid-market companies first — teams where one admin often owns data quality across both systems — and the same architecture scales to enterprise, multi-subsidiary NetSuite OneWorld environments. Data sync sits inside our broader Salesforce integration practice, and it starts from decisions, not connectors.
This is the canonical flow map we start every engagement from, then adapt to your data model. Still weighing connector against iPaaS against custom build? Start with our Salesforce NetSuite integration guide — this page assumes that decision is made and goes record-deep.
| Object | Direction | System of record | Typical cadence | Notes |
|---|---|---|---|---|
| Account ↔ Customer | BI-DIR | Split by field — Salesforce owns relationship and pipeline fields; NetSuite owns credit terms and financial fields | Near-real-time: event-triggered from Salesforce, scheduled poll from NetSuite | Create-or-update matching on a shared externalId — never name or email. On OneWorld, the subsidiary belongs in the key. |
| Contact ↔ Contact | BI-DIR | Salesforce, for relationship data | Near-real-time or scheduled | Same key discipline as accounts. Celigo's integration app syncs contacts alongside accounts and customers. |
| Opportunity (Closed Won) → Sales Order | SF → NS | Salesforce owns the opportunity; NetSuite owns the sales order it creates | Real-time on stage change | The canonical order-to-cash handoff, filtered on Stage = Closed Won. Order confirmation and status sync back so reps stop asking finance. |
| Item / Product + pricing | NS → SF | NetSuite — the item master | Scheduled batch, hourly to nightly | Inventory, non-inventory and service items plus item pricing; exchange rates alongside in multi-currency orgs. Reps quote from prices finance actually bills. |
| Invoice + payment status | NS → SF | NetSuite — AR never leaves the ERP | Frequent schedule; read-only in Salesforce | Reps see billing state on the account without edit rights. Deep-dive on this slice: our billing integration page. |
| Credit limit / amount due | NS → SF | NetSuite | Scheduled | Surfaced before quoting, so sales stops booking orders finance will put on hold. |
| Item fulfillment / shipping status | NS → SF | NetSuite — fulfillments are transformed from the sales order | Near-real-time via polling (saved search or SuiteQL) | NetSuite has limited webhook support, so "real-time" status from the ERP is a fast poll, not a push. Support answers "where's my order" from the CRM. |
The directions follow the pattern the whole ecosystem documents: Salesforce runs the front of the process — opportunities, quotes, contracts — while NetSuite runs orders, billing and fulfillment at the back. NetSuite publishes its default field mappings for reference, but every real org has custom fields, picklists and precision differences the defaults don't cover — which is why our first deliverable is always a signed field-mapping sheet, not a switched-on flow.
Every bi-directional flow needs a written answer to one question: when Salesforce and NetSuite hold different values for the same field, which one survives? There are four workable answers, and the choice is per field, not per system.
One system simply wins for a given object — Salesforce for leads and pipeline records, NetSuite for financial transactions. Simple to reason about, right where an object genuinely lives in one team's world. Wrong as a blanket rule for shared records like customers.
Ownership is split inside one record: sales owns billing contact and address fields from Salesforce, finance owns payment terms and credit limit from NetSuite, and each flow only writes the fields its side owns. This is the rule we implement most, because it matches how teams actually work.
The most recent modification survives, decided by compared timestamps. Acceptable for low-stakes descriptive fields; dangerous for anything financial. Wherever we use it, the losing value is logged so the overwrite is auditable instead of silent.
Genuine conflicts on money fields — credit terms, discounts, legal entity names — don't auto-resolve at all. The conflict lands in a review queue with both values and a named owner. Slower by design: some disagreements deserve a human decision.
Records will fail — a locked NetSuite record, a missing picklist value, a concurrency limit at quarter-end. The design question is never "will it fail" but where the failure lands, what retries automatically, and who gets paged. System-level patterns behind this — queues, throttling, event versus batch — live on our integration architecture page.
Every failed record lands in a queue with its payload and failure reason — a skipped record with no trace is the worst failure mode a sync can have.
Transient failures — HTTP 429 / SSS_REQUEST_LIMIT_EXCEEDED, timeouts, record locks — retry automatically with backoff. Idempotency keys make those retries safe.
Permanent errors need a human — the right human. Mapping and data errors route by which side owns the failing field, with an escalation path everyone has agreed to.
Four distinct services, and we are explicit about where each ends. Most engagements are configuration; custom development starts only where a template genuinely can't express your process — and we tell you which side of that line your requirement sits on.
Stand up the packaged tool that fits your stack — we hold a Celigo Partner credential and work daily with the wider ecosystem.
This is where sync projects are won or lost — the mapping and policy work no template ships with.
Custom development starts where configuration stops: flows and volumes no packaged app expresses.
Managed sync support for teams that don't want to staff integration operations internally.
Honest timeline: published implementation guides consistently report pre-built connector setups going live in two to four weeks, iPaaS builds in four to twelve, and fully custom API builds in two to six months. Data quality, custom-field count and subsidiary structure move you within those bands — we scope against your org, not the brochure.
A field-mapping workshop across every object that crosses systems: names, data types, picklists, currency precision, custom fields. Output: the draft mapping sheet.
System of record per object and field, dedup keys, conflict rules and cadence per flow — signed by sales ops and finance before anything is built.
Flows, filters and error handling built and tested in both sandboxes — planned around the fact that a NetSuite sandbox refresh changes internal IDs and can break integration tests.
Real transactions flow while the old process still runs. We compare record counts and values between systems until they match — then we trust it, not before.
Go-live with the error queue, alerting and named owners already in place, then hypercare through the first month-end close the sync has to survive.
Two published examples of the same discipline this page describes — one a Celigo-based ERP sync build, one an integration rescued from exactly the mapping failures listed above.
Items → Products, Salesforce Order → NetSuite Sales Order, and NetSuite Item Fulfillment → Salesforce, built on Celigo's Salesforce–NetSuite Integration App — the flow set from our published guide.
Inaccurate data mapping was causing sync failures and reporting errors between CRM and finance. We rebuilt the integration with automated bulk data management, secure real-time API sync and proper error handling.
The full method — flow selection, mapping, sandbox testing and monitoring on Celigo — is written up in our Salesforce & NetSuite integration blueprint.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges — as a Salesforce Partner and Celigo Partner that implements and integrates with NetSuite every week.
No flow gets switched on until the field-mapping sheet, per-field ownership and conflict rules are signed by sales ops and finance. Sync failures are usually policy failures — we fix the policy first.
Celigo, MuleSoft Composer, Oracle's connector, Breadwinner or a custom SuiteTalk REST build — we recommend per case, because we work at the API level underneath all of them.
Error queues, backoff retries and idempotent writes are designed in before go-live — not bolted on after the first duplicate invoice reaches a customer.
Cutover happens when parallel-run record counts and values match between Salesforce and NetSuite — a number both teams can check, not a demo both teams politely applaud.
Monitoring, triage and change management continue after go-live. If your sync is already live and misbehaving, our integration challenges guide maps the failure modes we rescue most.
We implement and integrate with NetSuite; we don't resell it. You get an honest read on what configuration covers, what needs custom SuiteScript or Apex, and what isn't worth building at all.
Match the cadence to the decision each record supports. Transactional handoffs — a closed-won opportunity becoming a sales order — justify event-driven, real-time flows. Reference data like items and pricing is fine on scheduled batches. Note that NetSuite has limited webhook support, so "real-time" out of NetSuite is usually a fast poll against a saved search or SuiteQL query rather than a push. Batch everything and data goes stale at critical moments; force everything real-time and you strain both platforms' API limits. Most healthy syncs mix the two, flow by flow.
Duplicates almost always trace to four gaps: no shared externalId between the systems, flows that create records instead of upserting, no idempotency keys so retries double-book, and matching on name or email instead of a stable key. The fix is structural — cross-reference IDs on every synced record, enforce upsert semantics, and give transactional flows an idempotency key. If duplicates already exist, remediate in order: freeze writes, agree the source of truth, dedupe, then re-enable the sync with those rules enforced.
Neither, globally — ownership is decided per object and, for shared records like the customer, per field. In practice Salesforce owns relationship and pipeline data, NetSuite owns financial and operational data, and financial transactions are almost always mastered in NetSuite. The decision gets written into a field-mapping sheet that sales ops and finance both sign, because an ownership rule nobody agreed to is a conflict waiting for month-end.
A deliberate conflict rule decides it: system priority (one side wins for that object), field-level priority (each side wins the fields it owns), last-write-wins by timestamp for low-stakes fields, or a manual review queue for money fields that deserve a human decision. What must never happen is a silent overwrite — every resolved conflict should be logged with both values so the outcome is auditable.
It can, if the sync isn't designed for them. NetSuite governs an account-level concurrency pool shared by all web services and RESTlet requests; the base limit depends on your service tier, and each SuiteCloud Plus license adds ten concurrent slots. Exceed the pool and requests fail with HTTP 429 and SSS_REQUEST_LIMIT_EXCEEDED. A well-built sync throttles inside the pool, queues bursts, and retries 429s with backoff. Salesforce applies its own rolling 24-hour API request allocation on the other side, so both budgets get sized during design — not discovered in production.
Every failed record should land in an error queue with its payload and failure reason. Transient errors — rate limits, timeouts, locked records — retry automatically with backoff; permanent errors route to a named owner: data and mapping errors to the CRM admin, financial mismatches to finance ops. Alerting fires on queue depth and age, not just individual failures, and a weekly reconciliation count between the two systems catches anything that slipped through silently.
Yes, with the right key design. In NetSuite OneWorld the same company can legitimately exist as separate customer records under different subsidiaries, so match keys must be composite — subsidiary plus external ID, never email alone. Both Celigo's integration app and Breadwinner support multi-subsidiary and multi-currency operation, including exchange-rate sync, and currency decimal precision differences between the platforms get mapped explicitly so amounts reconcile to the cent.
Bring us the objects that disagree, the duplicates that keep coming back, or the flow that fails every quarter-end. A discovery call gets you a straight read on whether the fix is mapping, conflict rules, throttling — or a rebuild.
Response within 24 hours — from an integration specialist, not a sales queue
