CRM Two-Way Sync (Salesforce)

The pain

Sales lives in the CRM. Fulfilment, revenue and cash live in NetSuite. Between them sits a spreadsheet, a nightly CSV, or a sales operations person who retypes closed-won opportunities into Sales Orders and then answers "has it shipped yet?" by opening two systems.

The symptoms are always the same. The same customer exists twice with two different names. A sales rep quotes a price that finance does not honour. A deal is marked closed-won but no Sales Order exists, so the forecast and the backlog disagree. An invoice is paid and the CRM still shows the account as owing. And when a field is edited on both sides in the same hour, whichever integration ran last silently wins — usually overwriting the correct value.

One-way sync is easy. Two-way sync is not, and the difficulty is entirely in conflict handling, identity resolution and idempotency. That is what this build is actually about.

What ECOSIRE builds

A bidirectional integration between your NetSuite account and your CRM org, built as a NetSuite-side SuiteScript 2.1 application plus the corresponding CRM-side configuration.

Object mapping

We map the objects you actually transact on, in both directions, with an explicit owner per field:

• Account ↔ Customer — including parent-child hierarchy, billing and shipping addresses, tax registration, terms, currency and Subsidiary in OneWorld.
• Contact ↔ Contact — with role, primary flag and multi-customer relationships preserved.
• Opportunity ↔ Opportunity or Estimate — stage, amount, expected close, probability and line detail.
• Quote ↔ Estimate — line items, pricing, discounts and expiry.
• Closed-won → Sales Order — the conversion path, with item resolution and segment defaulting.
• Sales Order, Item Fulfilment and Invoice status → CRM — so reps see fulfilment and payment state without a NetSuite licence.

Every field pair gets a direction and an owner during scoping: CRM-authoritative, NetSuite-authoritative, or bidirectional with a conflict rule. Nothing is left to "whichever ran last".

Identity and matching

Records are keyed on external IDs, not on names. We stamp a durable external ID on both sides — the NetSuite externalid and a custom field on the CRM record holding the NetSuite internal ID — so a rename never orphans a link. For records that already exist in both systems before go-live, we build a reconciliation pass: candidate matching by tax ID, domain, and normalised name, presented for human approval in a Suitelet rather than merged blindly. Unmatched records go to an exception queue with a reason, not into a silent duplicate.

Transport

NetSuite-side changes are captured by User Event scripts writing to a queue custom record, then pushed by a Map/Reduce script that calls the CRM API over N/https with OAuth credentials held in NetSuite Secrets. Inbound CRM changes arrive at a RESTlet authenticated with token-based authentication, or are pulled on a schedule where webhooks are not available. Both directions are queued rather than synchronous, so a CRM outage does not block a NetSuite user from saving a record.

Conflict handling — the hard part

This is where most CRM-to-ERP integrations quietly fail. We implement it explicitly:

• Loop prevention. Every write records its origin and a change hash. A sync-originated update never re-triggers an outbound sync for the same value, so records do not ping-pong.
• Idempotency. Every message carries an operation key. Replays and retries produce one result, not duplicate Sales Orders.
• Per-field precedence. Each bidirectional field has a declared winner, configurable on a mapping custom record — last-write-wins where that is genuinely fine, system-of-record-wins where it is not.
• Conflict quarantine. Where both sides changed a governed field within the same window, the update is held and surfaced in a conflict queue for a human decision, with both values and both timestamps shown.
• Ordering. Dependent records sync in dependency order — customer before contact before order — with retry-with-backoff when a parent has not yet landed.

Failure handling and visibility

Every sync attempt writes a log record: direction, object, external ID, payload hash, outcome and error. Failures retry with exponential backoff up to a configured ceiling, then land in a dead-letter queue with the original payload retained so it can be replayed after a fix. Saved searches and a dashboard portlet show queue depth, failure rate by object, oldest unprocessed item and open conflicts. SuiteFlow and scheduled alerting notify an owner when the queue ages past your threshold — because a sync that dies silently is worse than no sync.

Governance-aware design

NetSuite governance limits are a design constraint, not an afterthought. Batch sizes, Map/Reduce yielding, search paging and API call budgeting are built around your record volumes, established during scoping from your actual counts.

Who this is for

Companies running the CRM as the sales system of record and NetSuite as the financial and operational one, where the handoff currently involves manual re-entry or a fragile file drop. It suits OneWorld environments where a CRM account has to resolve to the right subsidiary and currency, and businesses whose reps need fulfilment and payment status without a NetSuite seat.

If you only need a one-directional lead-to-customer push, say so — we will scope the smaller thing and quote it lower rather than sell you a bidirectional engine you do not need.

How delivery works

1. Scoping call. We inventory the objects and fields on both sides, your existing duplicates, your record volumes, whether you run OneWorld, and — critically — which system is authoritative for each contested field. This session is where conflict policy is decided, not during the build. 2. Fixed quote. A written field-by-field mapping with directions, owners and conflict rules, the reconciliation approach for pre-existing records, and what is explicitly excluded. Price fixed against that document. 3. Build. Developed as an SDF project against your NetSuite sandbox and a CRM sandbox, with the mapping table as configuration rather than hard-coded logic. 4. Install in test. Deployed to sandbox with a full reconciliation dry run — we show you every proposed match before any merge. You test real deals end to end, from opportunity through Sales Order to invoice status returning to the CRM. 5. Install in production. After sign-off, deployed as an unmanaged bundle or SDF deployment. Go-live runs one direction at a time with the queue monitored, then bidirectional once clean. 6. Support. A defined support window for defect fixes and mapping adjustments, plus a handover session covering the queue, conflict resolution and how to add a field mapping yourself.

The code is yours: readable SuiteScript 2.1, your custom records, your mapping configuration. Unmanaged, no licence key, maintainable by your own team.

Honest limits

A sync cannot invent a policy you have not decided. If your business genuinely does not know whether sales or finance owns the billing address, we will surface that during scoping — the integration will expose the disagreement, not resolve it for you. Likewise, pre-existing duplicate data does not clean itself; the reconciliation pass makes it visible and actionable, and someone on your side still has to make the calls.