How to Build a Customer 360 in Salesforce and NetSuite

What Is a Customer 360, and Why Do Salesforce and NetSuite Need One Together?

A Customer 360 is a unified view of a customer built by combining data from every system that touches that relationship — in this case, Salesforce and NetSuite — into a single data warehouse or data lake that a data manager, analyst, or business intelligence tool can query directly. It is not a dashboard that simply links two systems together; it is a real data integration project that ensures data from both platforms reconciles into one trustworthy source.

For mid-market and enterprise IT teams, business data integration between Salesforce and NetSuite means separating transactional data flows from analytical loads, aligning two very different data structures, and preserving history across both systems as part of a broader master data management strategy. Done correctly, the result is a 360-degree customer view that sales teams, finance, and operations can all rely on, built on data synchronization patterns designed for each source system's actual architecture rather than a generic connector.

Key Takeaways

• A true 360-degree customer view requires combining Salesforce's relationship data with NetSuite's financial transactions and operational data in one target database, not just linking the two systems.

• NetSuite exposes two distinct integration paths — SuiteTalk (SOAP) and SuiteAnalytics Connect (JDBC) — and enterprise data analytics architectures should use each for what it's built for, not interchangeably.

• Automated schema discovery and column handling eliminate the manual DDL mapping that makes custom Salesforce NetSuite integration projects slow to build and fragile to maintain.

• A large set of NetSuite objects — more than 50, including Subsidiary, Department, Budget, Account, and Location — don't support incremental sync and need truncate-and-reload handling instead; treating them like real-time data causes silent data drift and hurts data quality downstream.

• Enterprise-grade performance tuning — a required 3-to-1 writer-to-finder thread ratio, dynamic time-slicing, and queue throttling — is what keeps a Customer 360 pipeline stable across multiple systems rather than timing out or deadlocking under load.

Why a Real Customer 360 Requires Both Salesforce and NetSuite

Salesforce and NetSuite each hold half of the picture. Salesforce owns the relationship — opportunities, cases, campaigns, activities, and customer information about how a customer engaged with your business. NetSuite owns the transaction — invoices, payments, subscriptions, revenue recognition, and the record of financial transactions that actually occurred.

A Customer 360 built from Salesforce data alone can tell you a customer is engaged and happy, right up until they're 90 days past due on an invoice nobody on the sales side can see. A view built from NetSuite alone can flag a churn risk in the numbers without any context on why — a support case that went unresolved, a renewal conversation that never happened. Enterprise data analytics that spans both systems closes that gap, and it's the reason mid-market and enterprise IT teams increasingly treat Salesforce NetSuite integration as a master data management problem that supports better business operations overall, not just a reporting project.

The challenge is that Salesforce and NetSuite weren't built to talk to each other. They use different schema conventions, different data structures, and — critically — different APIs depending on what kind of data you're moving and how quickly you need it to arrive.

Separating Transactional Sync From Analytical Loads in NetSuite

Quick answer: NetSuite offers two integration paths — SuiteTalk (SOAP) for transactional record updates, and SuiteAnalytics Connect (JDBC) for bulk analytical queries — and using the right one for each job is what keeps a Customer 360 pipeline stable.

SuiteTalk (SOAP) is NetSuite's transactional web services API. It's built for creating, updating, and syncing individual records — the kind of real time data movement a Customer 360 needs when a sales rep updates an opportunity and finance needs the related NetSuite record to reflect that change shortly after.

SuiteAnalytics Connect (JDBC) is a read-only, SQL-based connection designed for bulk analytical queries against NetSuite's data model. It's the right path for pulling large volumes of historical financial data into a data warehouse without putting transactional load on the same API that's handling live record updates.

Using SuiteAnalytics Connect for what should be a transactional sync — or routing high-volume analytical extracts through SuiteTalk — creates exactly the kind of API strain and performance degradation that undermines a Customer 360 before it's even fully built.

A well-architected integration keeps these data flows separate: SuiteTalk handles the record-level sync that keeps NetSuite data current, and SuiteAnalytics Connect handles the bulk historical loads that feed analytics without interfering with day-to-day business process execution.

Eliminating Manual Schema Mapping

Salesforce and NetSuite each have their own schema conventions, and neither maps cleanly onto a generic relational database without some translation. Building that translation by hand — documenting every field, every custom object, every naming collision — is exactly the kind of work that makes custom integration projects take months instead of days and puts data governance at risk from the start.

Automated schema discovery removes most of this by querying both systems' APIs directly and building the corresponding target schema automatically, including custom fields and objects layered on top of each system's standard data structures. Column widths can self-adjust automatically as source data changes, rather than requiring a DBA to widen a column manually after a value truncates.

There's also a specific naming-collision problem worth calling out on its own, because it's easy to conflate with an unrelated feature that also uses the letter "X." When a Salesforce or NetSuite field or table name collides with a reserved word in the target database, and no custom table prefix has been configured, the platform automatically appends an "X" to the end of that name — so a table that would otherwise conflict becomes something like ACCOUNTX — to make sure the schema compiles without a developer manually renaming anything. This is a completely separate mechanism from the "X" prefix used in history tracking, covered below; the two happen to share a letter, not a purpose.

Together, these capabilities mean the schema mapping that would otherwise consume weeks of a Customer 360 project happens automatically, and continues adjusting as either source system evolves.

Handling NetSuite's Non-Incremental Tables Correctly

Most NetSuite records support incremental sync — the pipeline can query only what changed since the last run. But a large set of NetSuite objects — more than 50 in total, including Subsidiary, Department, Budget, Account, AccountingPeriod, Bin, Classification, Location, Nexus, and TaxGroup — don't expose the change tracking that incremental sync depends on.

Treating these tables the same as transactional data is a quiet way to introduce data drift into a Customer 360: records get missed, updates don't propagate, and data quality erodes until a report doesn't reconcile. The correct approach is a truncate-and-reload mechanic for this full set of tables — replacing the full table contents on each sync rather than attempting to identify incremental changes that the source system doesn't expose.

Automating this distinction across the entire non-incremental object list, so these tables are handled differently by default rather than requiring a developer to remember and maintain that list manually, is a meaningful part of what ensures data stays accurate in a Salesforce NetSuite integration over time.

Bringing NetSuite Saved Searches Into the Data Model

NetSuite Saved Searches represent business logic your finance and operations teams have already built — filtered, calculated views of NetSuite data that reflect how your organization actually thinks about its financial transactions, not just the raw schema.

Rather than rebuilding that logic downstream, a well-designed integration can expose Saved Searches as standard tables in the target database, complete with normalized table names. Because Saved Searches don't have native unique record identifiers or modification timestamps, they can't be synced incrementally the way most NetSuite objects can — instead, each one is fully truncated and reloaded on every run, and a TOTALRECORDS column is updated at the end of each sync to store the exact record count the Saved Search returned during that execution.

That count gives finance and operations teams visibility into how a given search's results are trending over time, without anyone needing to reverse-engineer and reimplement the search's underlying logic in SQL.

Performance Tuning for Enterprise-Scale Integration

A Customer 360 spanning two enterprise systems moves meaningful volume across multiple systems, and the difference between a pipeline that runs reliably and one that times out or deadlocks under load comes down to tuning, not raw capacity.

Maintaining a 3-to-1 ratio of database writer threads to finder threads isn't a suggested starting point — it's a required configuration for high-volume sync runs, because writing to the target database and querying the source system are different kinds of work with different bottlenecks. Getting this ratio wrong is a direct path to target database write bottlenecks and transactional deadlocks, not just slower throughput.

Dynamic time-slicing addresses a related but separate problem: when a query window returns more records than expected, the pipeline shortens the time interval and re-queries, rather than attempting to process an oversized batch that risks timing out. And in-memory queue throttling protects against a different failure mode entirely — if writing to the target database becomes a bottleneck, throttling pauses extraction until the queue clears, rather than letting memory usage climb until the process fails.

None of these settings are exotic — they're standard enterprise integration concerns — but getting them right, and treating the 3-to-1 thread ratio as a hard requirement rather than a tuning suggestion, is what separates a Customer 360 pipeline that holds up in production from one that works fine in a demo and falls over under real load.

Data Sovereignty and History Tracking Across Both Systems

For regulated mid-market and enterprise organizations, where the integrated data physically resides matters as much as what it contains. A Customer 360 architecture that routes Salesforce and NetSuite data through a vendor's own infrastructure on its way to your target database introduces a data sovereignty question that a compliance and data governance review will eventually surface — regardless of how good the resulting unified view is.

A self-hosted or customer-hosted target database keeps both source systems' data inside your own environment throughout the integration, avoiding that third-party custody question by architecture rather than by contract.

History tracking adds another layer of value on top of data sovereignty — and it's worth being precise about how it works and where it's available. When history tracking is enabled, the platform automatically generates an audit-trail table using a leading "X" — for example, an XACCOUNT table — to hold historical record versions over time.

This is a row-by-row, transactional write pattern, which is why it's only available on row-oriented database targets. Columnar, bulk-loaded data warehouses such as Snowflake, Amazon Redshift, Vertica, and Greenplum don't support the rapid, transactional writes history tracking requires, so it's unavailable on those platforms regardless of whether you're replicating Salesforce or NetSuite data — standard, flat replication is still fully supported there, just without the historical "X" tables.

For a Customer 360 used in audit, compliance, or trend-analysis contexts on a row-oriented target, having a queryable history of how a customer's data changed is often as valuable as the current snapshot itself.

Bringing It Together: What a Production-Grade Customer 360 Looks Like

A Customer 360 that holds up in production combines several things working together: SuiteTalk handling transactional sync while SuiteAnalytics Connect handles bulk analytical loads, automated schema discovery eliminating manual mapping across both systems, correct handling of NetSuite's full list of non-incremental reference tables, Saved Searches exposed as queryable tables with accurate record counts, enterprise-grade performance tuning to keep the pipeline stable at scale, and a customer-hosted architecture that keeps data sovereignty and history tracking under your own control.

The payoff is an improved customer experience on the front end — sales teams working from customer information that actually reflects financial reality — and a more reliable foundation for business intelligence on the back end, where finance, operations, and analytics teams are all querying the same unified view instead of reconciling conflicting reports from separate systems.

Sesame Software's platform is built to handle each of these pieces as part of a single, no-code Salesforce NetSuite integration — separating transactional and analytical NetSuite traffic, automating schema discovery and mapping, correctly managing the full set of non-incremental tables, exposing Saved Searches as tables, and running entirely inside your own environment rather than Sesame Software's infrastructure.

Ready to build a Customer 360 your sales teams, finance, and operations can all trust? Talk to a Sesame Software data expert today.

Frequently Asked Questions

What's the difference between SuiteTalk and SuiteAnalytics Connect for NetSuite integration? SuiteTalk (SOAP) is NetSuite's transactional API, built for near real-time record creation and updates. SuiteAnalytics Connect (JDBC) is a read-only, SQL-based connection designed for bulk analytical queries. Using each for its intended purpose keeps transactional sync and analytical data flows from competing for the same API resources.

Why do some NetSuite tables need a different sync approach? More than 50 NetSuite objects — including Subsidiary, Department, Budget, Account, AccountingPeriod, Bin, Classification, Location, Nexus, and TaxGroup — don't expose the change-tracking data that incremental sync relies on. These objects need a truncate-and-reload approach instead, replacing the full table on each sync rather than attempting to identify incremental changes.

Can NetSuite Saved Searches be integrated into a Customer 360 database? Yes. Saved Searches can be exposed as standard tables in the target database. Because they lack native record IDs and timestamps, they're fully reloaded on each sync, with a TOTALRECORDS column tracking the exact record count returned at each run — preserving the business logic already built into the search without reimplementing it in SQL.

Why does data sovereignty matter for a Salesforce NetSuite Customer 360? Where integrated data physically resides during and after integration determines whether a third-party custody question arises during a compliance or data governance review. A self-hosted or customer-hosted target database keeps both Salesforce and NetSuite data inside your own environment throughout the process.

Does history tracking work the same way on every database target? No. History tracking generates "X"-prefixed audit tables (like XACCOUNT) through row-by-row transactional writes, so it's only supported on row-oriented database targets. Columnar data warehouses like Snowflake, Redshift, Vertica, and Greenplum support standard replication but not history tracking, regardless of source system.

What causes a Salesforce NetSuite integration to time out or deadlock at scale? Most often, deviating from the required 3-to-1 database writer-to-reader thread ratio, oversized query batches that exceed what the pipeline can process in one pass, or unthrottled extraction that outpaces how quickly data can be written to the target. Performance tuning parameters address each of these specifically.

Is a Customer 360 the same thing as a data warehouse? No. A data warehouse or data lake is the storage layer that holds unified Salesforce and NetSuite data. A Customer 360 is the resulting unified view built on top of that storage — the queryable, trustworthy dataset that sales teams, finance, and business intelligence tools actually use once the data integration work is done.