HubSpot NetSuite Integration: What the Sync Won't Do

The install button wasn't there.

That's how a HubSpot–NetSuite integration for a B2B software company began: an admin with every relevant NetSuite feature enabled, SOAP and REST web services, token-based authentication, server SuiteScript, SuiteAnalytics, all of it, staring at a SuiteApp listing with no way to install it. NetSuite support said HubSpot, as the app's publisher, had to permission the app to the account. HubSpot support kept pointing to a knowledge base article that didn't resolve it. Each vendor pointed at the other. It took forcing a live screen-share with HubSpot support to get past a missing button, and it cost roughly three weeks.

That story sets expectations correctly. The HubSpot NetSuite integration works, and it's the right choice for most companies running both. But it has specific limits that the documentation understates, and every one of them surfaces after you've committed. Here are the three that cost us the most time.

Lookup fields don't sync, and the obvious workaround fails

NetSuite lookup fields, the ones that reference another table, don't come across the connector. In this project that meant Original Lead Source (which references a campaign table), the BDR owner (a filtered employee list), and Competing Software (a competitor list). Those were the three fields sales most cared about. The obvious workaround, creating a text field with a matching dropdown, didn't hold. What worked was creating new plain-text fields in NetSuite specifically for the sync, then mapping them to proper HubSpot dropdowns through a workflow on the HubSpot side. Two extra fields per lookup, and a workflow to translate. Budget it.

It also reshaped scope. The opportunity object turned out to be almost entirely lookup fields, and the BDR team using HubSpot didn't manage deals anyway. So deal sync got deprioritized entirely, which was the right call and one we wouldn't have made without hitting the lookup limit first.

Your sandbox has different IDs than production

This one bites at go-live. A NetSuite sandbox is a point-in-time replica, and every record in it has an internal ID that differs from its production counterpart. If you've been building and testing the sync against the sandbox, the HubSpot records now carry sandbox IDs. Connecting the same portal to production doesn't fix that; it creates conflicts. The clean sequence is to disable the sync, delete every synced record from HubSpot, reconnect to production, and let it repopulate with correct IDs. Plan that step into the go-live runbook explicitly, because nobody enjoys discovering it on the day.

The two-vendor blame loop is a real cost

Back to the install button. When an integration spans two platforms, support tickets bounce, and the bouncing has no owner. A partner's job in that moment is unglamorous: escalate relentlessly, get both vendors on a live call, and refuse to accept "that's the other side's issue" as a resolution. That escalation work is the difference between a three-week delay and a three-month one.

None of this is a reason to avoid the native connector. A custom middleware build would have cost multiples of this project and given the client something to maintain forever. The native integration was right. It just needed someone who'd hit its limits before and knew which ones would cost weeks.

If you're scoping a HubSpot–NetSuite project, ask your partner to name the lookup fields you care about before signing. If they don't ask which of your fields are lookups, they haven't done this before.