Submission on behalf of Martin Kiehn.
Intro
A long-standing integration between HubSpot and NetSuite needed a more intelligent way to handle duplicate contact issues.
The challenge
Our client had HubSpot connected to NetSuite to sync contact data between their CRM and ERP systems.
HubSpot contact records were created in multiple ways:
- Visitors submitting forms or browsing the website.
- Internal departments creating contacts in NetSuite, which the integration then syncs into HubSpot.
This setup sometimes resulted in multiple HubSpot contact records for the same real-world person, each with a different email address. Since HubSpot uses the email address as a unique identifier, conflicts would occur if someone changed a NetSuite record’s email to one already used in another HubSpot contact.
When this happened, HubSpot would reject the update — and someone in the IT department had to manually intervene.
The customer wanted a more automated way to handle these errors, but only when it was safe to do so. In some cases, a smart recovery was possible. In others, manual intervention remained the right choice. The key was being able to tell the difference.
Our solution
We designed a flexible, layered solution using Celigo’s new API Builder. The goal was to preserve clean architecture while making room for complex decision logic — without cluttering the main integration flow with conditionals and edge-case logic.
Here’s how we did it
1. Detecting the conflict
When a HubSpot API call failed due to an email conflict, the flow intercepted the error and routed it to a dedicated branch designed to evaluate recovery options.
2. Custom API for decision logic
We built a custom API using Celigo’s API Builder. This API:
- Looked up both HubSpot contact records: the one being updated and the one already using the conflicting email address.
- Analyzed their metadata, ownership, and creation source to decide whether a recovery strategy was available.
- Returned a response indicating either:
- A recommended recovery path (e.g., merge, reassign email, archive old contact), or
- That the error should be surfaced to IT as usual.
This API was kept modular and easy to adjust as new edge cases emerged over time.
3. Triggering recovery flows
If a recovery plan was returned:
- The main flow continued uninterrupted.
- A side process was launched to execute the recovery using a dedicated error-handling flow — keeping responsibilities clearly separated and the main flow clean.
If no recovery was possible, the original error was passed through as before, allowing the IT team to handle it manually in their existing interface.
The result
The new logic dramatically reduced the number of HubSpot sync failures requiring manual attention, while still preserving the integrity of the integration. Most importantly, it avoided the trap of burying critical flow logic under error-handling complexity.
By isolating the decision-making and recovery steps into their own API and flows, we delivered a clean, maintainable architecture — and gave the IT department time back to focus on more strategic tasks.
Main flow DF02
API01 flow - analysing and deciding on strategy
DF08 Resolve conflict and recover
