Most integration failures are prepared weeks before the first record moves — in dirty data, unmapped fields, unowned records and untested edge cases. This page is the working checklist: four phases, 18 items, each with what to do, why it matters, and who owns it. Decide, clean, map, test, cut over, govern.
Trusted by 500+ organizations — including teams preparing their first Salesforce–NetSuite integration and teams re-running readiness after a rescue, with Twopir Consulting.
Built for Integration Readiness
Ecosystem post-mortems of failed Salesforce–NetSuite projects keep naming the same causes — and almost none of them are tooling. They are preparation gaps, and every one of them is preventable. That is the entire case for working a checklist.
An integration surfaces every duplicate and inconsistency that already exists in either system. Skip the cleanup and the flows faithfully copy the mess — duplicate customers in NetSuite become duplicate invoices, and finance stops trusting the sync in its first month.
Finance updates credit terms in NetSuite while sales edits the same account in Salesforce. Without master-data ownership decided per object — and per field for shared records — the two systems overwrite each other and every conflict becomes an argument.
Salesforce Accounts are not NetSuite Customers, and the two platforms differ in field names, data types, picklist values, date formats and currency decimal precision. Every mismatch that isn't identified before go-live is a sync error waiting for production data.
Integrations routinely pass sandbox testing on typical transactions and then fail on unusual-but-valid data — multi-currency orders, partial fulfillments, credit holds — or crumble at real production volumes and peaks. Edge cases belong in the test data on purpose.
Migration-readiness guides call late-discovered integration gaps one of the most common and most avoidable causes of go-live delays. The item that slips a launch is rarely exotic — it's a sandbox nobody provisioned or a mapping nobody signed.
The build team rolls off, and there is no error queue anyone reads, no owner for mapping changes, no change control on new fields. The first silent failure surfaces at month-end close — as a deal closed in Salesforce with no sales order in NetSuite.
A Salesforce–NetSuite integration checklist is the ordered set of decisions, cleanup tasks and verifications a team completes around connecting Salesforce, the CRM, with NetSuite, the ERP — organized into four phases: before you pick an approach (goals, object inventory, master-data ownership), before build (data cleanup, field mapping, sandbox access, API limits), during build (edge-case test data, error-handling rules, cutover plan), and after go-live (monitoring, ownership, change management, success metrics). Every item names what to do, why it matters, and who owns it.
The checklist deliberately isn't a tool decision. Whether the flows end up on Celigo integrator.io, MuleSoft Composer, Oracle's NetSuite Connector for Salesforce, Breadwinner or a custom SuiteTalk REST build, the same decisions have to exist first — and the approach comparison itself lives on our Salesforce NetSuite integration guide. The checklist's job is to make sure the tool inherits decisions, not disputes.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges, and this checklist is the artifact we start nearly every one of those engagements with. It sits inside our wider Salesforce integration practice — and it works just as well as a self-assessment before you ever talk to us.
Work it top to bottom; the numbering is the recommended order. Items 1–5 shape which integration approach you should even consider, 6–10 make the build safe to start, 11–14 make go-live boring, and 15–18 keep the integration healthy after the project team rolls off. Each item: what to do, why, and who owns it.
Decisions that shape the tool choice — make them first, or the tool makes them for you.
Write down the business goals and the metrics that will prove them
Define what "integrated" means for your team in outcomes — no re-keying of closed-won orders into NetSuite, invoice and payment status visible to reps, one number for bookings — and pick the measures you will check after go-live, such as data accuracy and hours of manual entry removed. Item 18 is impossible without this one.
Owner · Executive sponsor + RevOps
Inventory the objects and fields that actually need to move
List the record types in scope — typically Account ↔ Customer, closed-won Opportunity → Sales Order, items and pricing into Salesforce, invoice and payment status back into Salesforce — and count the custom fields on each. Scope creep starts here; so does honest budgeting.
Owner · Salesforce admin + NetSuite admin
Decide master-data ownership per object — in writing
One system gets to be right for each object, and for shared records like the customer, ownership goes down to field level: the common pattern is Salesforce winning relationship and pipeline fields while NetSuite wins financial and operational ones. Undecided ownership is the root of overwrite loops and month-end disputes.
Owner · Sales ops + finance leadership, jointly signed
Agree direction and cadence for every flow
Per flow: one-way or bi-directional, real-time or scheduled batch — and know that NetSuite's limited webhook support means "real-time" usually means polling. The record-level detail behind these choices lives on our Salesforce NetSuite data sync page.
Owner · Integration lead
Map the constraints that shape tool choice and budget
Know your NetSuite account's shared API concurrency pool (service-tier base, plus 10 slots per SuiteCloud Plus license), your Salesforce org's daily API allocation, whether you run multi-subsidiary OneWorld, and that NetSuite SOAP web services are being retired in favour of REST. These facts decide which approaches are viable — and what they cost to run; scope them against our integration cost breakdown before anyone quotes you.
Owner · Integration architect
Preparation that makes the build safe to start — cleanup, mapping, access and limits.
Clean and dedupe the data in both systems first
An integration surfaces every inconsistency and duplicate that already exists in either system. Merge duplicate accounts and customers, retire stale records, standardize names, addresses and picklist values — before any records move. Cleanup after go-live costs multiples of cleanup before it.
Owner · CRM manager + finance data owner
Choose the dedup key the sync will match on
Flows should match on a shared external ID and upsert — update-or-create — never create blindly or match on name and email. In multi-subsidiary NetSuite OneWorld, the same company legitimately exists once per subsidiary, so the key must be composite and include subsidiary.
Owner · Integration lead
Run the field-mapping workshop and sign the output
Map the two data models field by field — Accounts against Customers, Opportunities against Sales Orders, products against items — map every custom field explicitly, review NetSuite's default mappings, and flag picklist, date-format, validation-rule and currency-precision mismatches. The output is a field-mapping sheet both teams sign, which also becomes the change-control reference in item 17.
Owner · Both admins, facilitated by the integration partner
Provision sandbox access on both sides
You need a NetSuite sandbox and a Salesforce sandbox before the first flow is built — with sensitive data masked. Plan around one NetSuite quirk: a sandbox refresh changes internal IDs, which can break integration tests that reference them, and sandbox accounts carry their own lower concurrency limits.
Owner · IT / both platform admins
Set up integration identities and review API limits
Create a dedicated integration user in each system with least-privilege permissions and a defined OAuth policy — never a person's login. Confirm the planned flow volumes fit inside NetSuite's concurrency pool and Salesforce's daily API allocation, with headroom for quarter-end peaks.
Owner · Integration architect + security
Verification that makes go-live uneventful — test what production will actually send.
Build test data that includes the edge cases
Integrations commonly pass testing on typical transactions and fail on unusual-but-valid data. Seed the sandbox deliberately with the awkward records: multi-currency orders, multi-subsidiary customers, partial fulfillments, credit holds, discounts, and the longest text values your fields allow.
Owner · QA lead + both admins
Define error-handling rules before the first flow goes live
Decide now: which failures retry automatically and with what backoff, which land in an error queue, who gets alerted, and how retries stay idempotent so a replay never creates a duplicate. An error path designed after the first production failure is designed under the worst possible conditions.
Owner · Integration lead
Reconcile a trial run against the legacy data
Run a trial migration and a parallel period in sandbox, then reconcile record counts and amounts against the legacy source — and review the integration logs — before anyone schedules cutover. Reconciliation is what turns "the demo worked" into "the numbers match".
Owner · QA lead + finance
Write the cutover plan — sequence, freeze, rollback
Name the go-live sequence, the data-freeze window, who confirms each step, what triggers a rollback and how a rollback works. A cutover plan is cheap to write and priceless the one time you need the rollback half of it.
Owner · Project manager
Governance that keeps the integration healthy after the project team rolls off.
Stand up monitoring and an error queue someone reads
Silent failures are the canonical integration disease: a record fails validation, the flow skips it, and the gap surfaces weeks later at month-end close. Alerts, a visible error queue and retry visibility make failures loud while they are still small.
Owner · Named sync owner
Assign ongoing ownership by name
One named person owns sync errors day to day; one named forum approves mapping and rule changes. "The integration team" stopped existing when the project closed — governance only works when the owner is a name, not a group noun.
Owner · Operations leadership
Put change control around both orgs
New fields, renamed picklist values and new validation rules in either system are checked against the signed field-mapping sheet before they deploy. Mapping drift — each org evolving while the mapping stands still — is how healthy integrations decay into flaky ones.
Owner · Both platform admins
Review the success metrics on a schedule
Return to the item-1 metrics on a regular cadence — data accuracy and consistency between the systems, manual entry actually removed, error rates trending down. A periodic health check is the difference between an integration that is maintained and one that is merely still running.
Owner · Executive sponsor
Phased delivery models published by NetSuite implementation partners follow the same arc — discovery and scoping, design, data migration, integration, testing and UAT, cutover, then post-go-live hypercare — so this checklist maps cleanly onto whichever delivery methodology your integration partner runs.
A checklist tells you what has to be decided. It cannot make the contested decisions for you — when sales and finance genuinely disagree about who owns the customer record, someone experienced has to broker field-level ownership both sides will actually honour. It cannot judge trade-offs it has never seen, like whether your order volumes justify an iPaaS or your NetSuite customizations will fight a packaged connector. And it cannot do the work: cleanup, mapping, testing and cutover are weeks of disciplined effort even when every box is understood.
If the checklist raises questions your team can't settle internally, that is the signal to bring in help — it's precisely what our Salesforce NetSuite integration consulting engagements exist for, and arriving with a half-worked checklist makes that engagement faster and cheaper, not redundant.
The platforms provide the APIs, the tools provide the plumbing — the checklist provides the decisions. Twopir runs all three layers: we assess readiness, implement the flows, configure them to your process, and build custom where packaged tools stop.
We run this checklist against your actual orgs and produce the gap report: what's decided, what's missing, and what blocks a safe build.
We stand up the integration on the approach your constraints point to — packaged where packaged fits.
We encode the checklist's decisions into the tool: your mappings, your keys, your rules — not template defaults.
Where configuration ends and your process doesn't, we develop — on current, supported APIs.
Worked setup detail — flows, filters, sandbox testing and activation — is published in our Salesforce & NetSuite integration blueprint using Celigo.
Timelines depend on approach and on how much of the checklist is already done: published implementation guides put pre-built connectors at roughly 2–4 weeks, iPaaS projects at 4–12 weeks and custom API builds at 2–6 months, with one guide scoping a realistic first integration — data-model workshops included — at about eight weeks. Clean data and a signed mapping sheet are the two biggest accelerators.
We work phases 1–2 of the checklist against your orgs: goals, object inventory, constraints, data quality — and surface every gap before it costs schedule.
Ownership brokered and signed per object and field; the field-mapping workshop run; dedup keys, direction and cadence agreed for every flow.
Flows built in both sandboxes against the signed sheet — with the NetSuite sandbox-refresh ID quirk and lower sandbox limits planned around, not discovered.
Edge-case test data, a reconciled trial run against legacy numbers, and error-path rehearsal — the go/no-go evidence, not a demo.
The written cutover plan executed, then hypercare: monitoring live, error queue owned by name, change control active, metrics reviewed on schedule.
One engagement shows what the checklist enables; the other shows what it prevents. Both are published with their numbers and their context.
Items to products, orders to sales orders, fulfillments back to Salesforce — the flows this checklist prepares, run through Celigo's Salesforce–NetSuite Integration App.
Inaccurate data mapping had caused sync failures and reporting errors — exactly what phase 2 of this checklist exists to prevent. Rebuilt with secure APIs, bulk data management and real error handling.
More on the approach behind these engagements: Celigo-powered Salesforce & NetSuite integration made easy and our client success stories.
A checklist is only as good as the judgment applied at each box. Ours comes from running these integrations — and rescuing the ones that skipped the preparation.
Requirements documents record what everyone wants. We broker the harder artifacts — a signed ownership sheet and a signed mapping sheet — because those are what actually prevent overwrite loops and month-end disputes.
As a Salesforce Partner and Celigo Partner with 250+ deployments delivered, the order-to-cash, item and invoice-status flows on this page are work we ship, not theory we summarize.
We implement and integrate with NetSuite — SuiteTalk REST, SuiteScript, RESTlets, OneWorld constraints — and we don't resell the ERP. Our advice on approach and scope has no license commission behind it.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges — including teams where one admin owns readiness across both systems.
Half this checklist happens after go-live. Our engagements carry through monitoring, ownership handover, change control and the first metric reviews — because that is when integrations quietly succeed or quietly rot.
Four things before you even pick a tool: write down the business goals and the metrics that will prove them; inventory the objects and fields that actually need to move; decide which system owns which data, per object and per field, in writing; and agree the direction and cadence of every flow. Teams that skip these decisions end up rebuilding flows after go-live — and every tool choice gets easier once the decisions exist.
Both, before any records move. An integration surfaces every duplicate and inconsistency that already exists in either system, so dedupe accounts and customers on each side, retire stale records, and standardize names, addresses and picklist values first. Then agree the dedup key the sync will match on — a shared external ID, extended to include subsidiary in multi-subsidiary NetSuite OneWorld accounts — so flows update existing records instead of creating new ones.
Sales and finance leadership together, before build — not the integrator mid-project. The common pattern is that Salesforce wins relationship and pipeline fields while NetSuite wins financial and operational fields, with ownership defined at field level for shared records like the customer. The decision gets written into a signed ownership sheet so later conflicts have a reference instead of an argument.
It aligns the two data models field by field: Salesforce Accounts against NetSuite Customers, Opportunities against Sales Orders, products against items. It maps every custom field explicitly, reviews NetSuite's published default mappings, and flags the mismatches that break syncs later — picklist values, date formats, currency decimal precision and validation rules. The output is a field-mapping document both teams sign, which then anchors change control after go-live.
Yes — build and test in a NetSuite sandbox and a Salesforce sandbox before user acceptance testing, with sensitive data masked and with test data that includes edge cases, because integrations commonly pass on typical transactions and fail on unusual-but-valid ones. Reconcile a trial run against the legacy numbers before scheduling cutover, and plan around one NetSuite quirk: a sandbox refresh changes internal IDs, which can break integration tests that reference them.
Four standing pieces: monitoring with an error queue someone is named to read; a named owner for sync errors and mapping changes; change control so new fields and picklist values in either org are checked against the signed mapping sheet before they deploy; and a periodic review of the success metrics defined at the start — data accuracy, manual work actually removed, and whether the two systems still agree.
It depends mostly on the approach and on how much of the checklist is already done. Published implementation guides put pre-built connectors at roughly two to four weeks, iPaaS projects at four to twelve weeks, and custom API builds at two to six months — and one guide scopes a realistic first integration, including the data-model workshops, at about eight weeks. Clean data and a signed mapping sheet are the two biggest accelerators on any of those paths.
Bring us the checklist as far as you've worked it — even half-finished — and we'll turn the open items into a scoped, phased plan: decisions brokered, data cleaned, mappings signed, flows tested, and a go-live somebody monitors.
Response within 24 hours · Readiness gaps named on the first call
