What follows isn't a theoretical guide or a best-practices whitepaper. This is the story of an actual integration project we completed: a custom bi-directional NetSuite/HubSpot integration using AWS as middleware for a manufacturing company with complex requirements that no off-the-shelf connector could handle.
The project spanned several months, involved late nights, holiday cutovers, a 147-item UAT tracker, and a few lessons. We worked alongside a NetSuite implementation partner, navigated shifting requirements, and ultimately delivered a system that converts closed-won HubSpot deals into NetSuite sales orders in near real-time, while syncing 30,000+ products nightly.
We're sharing this because the gap between "how integrations should work in theory," and "what actually happens when you're three days from go-live and someone just added fifteen new UAT items," is vast. If you're considering a similar project, the specific challenges we faced — and how we solved them — might save you significant time and frustration.
This is what it actually looked like...
HubSpot offers a native NetSuite connector that handles the syncing of basic invoices and a couple of data points. We used it for exactly that: pulling invoices from NetSuite into HubSpot. But that's where native solutions stopped helping us. The moment you have complex requirements, things like multiple customer addresses per sales order, real-time deal-to-sales-order conversion, or nightly product catalogue syncs from saved searches, you're in custom territory.
In our case, the requirements included:
Syncing 30,000+ products nightly from NetSuite saved searches (a nifty way of just getting relevant Items to HubSpot!)
Converting closed-won HubSpot deals into NetSuite sales orders in near real-time
Handling multiple different customer addresses per order (shipping, billing, invoice, transit, etc.)
Pulling credit limits and open balances back to HubSpot to prevent sales reps from creating deals with customers who have payment bans
This is what our goal looked like to begin with:
Before writing a single line of code, we created what became the most important artifact of the entire project: a comprehensive solutions document. This wasn't a two-page brief. It was a substantial document stored in Google Drive that became our single source of truth. The document covered:
The entire integration flow, including how data would move in both directions
Which triggers would initiate syncs
Which properties would be sent
How HubSpot would be configured to support the integration, including custom properties, workflows, and permission sets
Here's what made it valuable: everyone understood it and signed off on it. This meant that any changes were treated as such and could easily be seen in the big picture. It made for a much smoother relationship between all stakeholders.
Our client was migrating from a legacy CRM system, as Netsuite was being implemented. So we needed to map three systems simultaneously: the old CRM's fields, the new HubSpot properties, and NetSuite's fields. We created a massive mapping spreadsheet in collaboration with the NetSuite implementation partner.
This is where we hit one of those small snags that became a running joke on a project. Midway through the build, someone applied a filter to the mapping spreadsheet and forgot to remove it. A handful of properties were hidden from view, and nobody noticed until we started testing and wondered why a few fields weren't syncing.
The fix took about ten minutes once we spotted it. But it's a good reminder: before you start building, have someone double-check that counts are what they should be, and you're looking at the complete dataset. A small thing, but easy to miss.
This particular integration had a requirement that separated it from typical implementations: a single sales order could have up to four different companies associated with it, and each company could have up to four different addresses (n really). In NetSuite, this is manageable because addresses are stored in a sub-table. In HubSpot, addresses are essentially a one-to-one relationship with records unless you create additional properties.
We spent considerable time figuring out the address logic. We ultimately solved it using HubSpot association labels. A deal could have up to four companies associated with it, labeled as "Primary Customer," "Invoice Customer," "Shipping Customer," and so on. Each company could have a default address, shipping address, invoice address, and transit address stored in custom properties.
The integration logic then followed a hierarchy: when syncing a deal to a sales order, we'd first sync the associated companies to NetSuite, retrieve their NetSuite company IDs and address IDs, write those back to HubSpot, and then use calculated properties on the deal to determine which specific address combinations should populate the sales order.
Critical insight: Don't proceed with integration development until address logic (or similarly complex relational logic) is fully documented and agreed upon. This is true in most ERP integrations.
Stay tuned for Part II of our series, Building a Bi-Directional NetSuite/HubSpot Integration. We'll discuss using AWS as a middleware layer, performing nightly syncs, building a credit limit enforcement, and much more!
If you're ready to discuss a HubSpot/NetSuite integration with a set of seasoned experts, please reach out to Periti Digital today!
The native connector handles basic invoice syncing well, but it simply can't support complex requirements. Once your project involves things like real-time deal-to-sales-order conversion, nightly syncs of 30,000+ products, multiple address types per order, or pulling credit limits back into HubSpot, a custom solution becomes necessary. Off-the-shelf connectors are designed for common use cases. Ours just happened to fall outside that scope.
The solutions document was a comprehensive, single source of truth covering the entire integration; it covered everything from data flows, to sync triggers, to HubSpot configurations, and more. Its real value came from the fact that every stakeholder read and signed off on it. That meant changes were visible in context, expectations were aligned from the start, and the project team wasn't constantly second-guessing what had been agreed upon.
The team built a detailed mapping spreadsheet in collaboration with our NetSuite implementation partner, covering fields from the legacy CRM, HubSpot, and NetSuite simultaneously. The key lesson learned? Always verify that you're looking at the full dataset. A simple filter left on the spreadsheet hid several properties during the build, and it wasn't caught until testing began.
HubSpot association labels became the solution. Each deal could be linked to up to four companies, each labeled by role (Primary Customer, Shipping Customer, Invoice Customer, etc.). Custom properties on each company record stored the different address types, and calculated properties on the deal determined which address combinations flowed into the NetSuite sales order.
In most ERP integrations, address handling is far more complex than it first appears. In this project, a single sales order could involve up to four companies (each with multiple address types) and HubSpot and NetSuite handle addresses very differently under the hood. Trying to sort this out mid-build or during testing can cause significant delays, so it needs to be fully documented and agreed upon before development begins.
Beyond the technical complexity, the project involved navigating shifting requirements, a 147-item UAT tracker, holiday cutovers, and the kind of last-minute additions that happen on most large integration projects. The blog series is designed to share these honest, on-the-ground realities. Because the gap between how integrations are supposed to go and how they actually go is where the most useful lessons live.