HubSpot + NTS Informatica integration

NTS Informatica, based in Rimini, sells Business Experience through a network of partners. NTS calls the product the evolution of Business Cube and delivers it on premises, on the customer’s own Microsoft SQL Server, with a hosted Business Cloud Platform service as the alternative. When a company on Business opens a sales office abroad, or buys a business that already sells from HubSpot, the ledger and the pipeline end up in two systems that were never introduced.

Sellers then work blind. They cannot see which accounts have open orders, what was invoiced last month, or whether a quote they sent ever became an order, and the order desk retypes every won deal into Business. NTS sells a CRM module inside Business and Ydea, a cloud CRM, so the real question is how the ERP and the HubSpot portal the sales team already uses can agree.

NTS answered a version of that question for web shops, in a module its version notes list in every generation from Business NET 2015 onward. The e-commerce connection module builds a transit database with views over Business data and tables an outside application can write into, and NTS’s help documents it column by column, in Italian. That documented contract is what makes a HubSpot integration with Business predictable.

Six flows carry the value, four in and two out. Customers from the CLIENTI view become HubSpot companies, items from ARTICO become products, and open orders from IMPEGNI and sales documents from VENDITE land on custom objects associated to the company. Going the other way, a lead qualified in HubSpot becomes a row in LEADSX, and a won deal becomes an order in TESTORDX and MOVORDX.

Keys come from Business. A customer keys on its Business code, scoped by the company code, because one transit database can serve more than one company. Orders and sales documents key on their year, series and number, never the number alone. VENDITE holds one row per document line, so the service rolls the lines up into one record per document before it writes.

Writes carry our key in NTS’s external code fields. The HubSpot deal becomes the order’s external reference, and Business fills in its own document number once the import accepts the row. That returned number is what links the two records for good.

The runtime is a polling sync over SQL. A service holds a SQL login on the transit database with read access to the views and write access to the tables meant for outside applications. It reads each view for rows whose last-update column is newer than the watermark it stored for that view, upserts the changes into HubSpot as batches keyed on the Business codes, then runs a separate association pass.

Writes are two steps with a wait between them. The service inserts a lead or an order, and NTS’s scheduled import program takes it into Business and records the outcome in the row’s import status. S means imported, with the Business code filled in. E means rejected as wrong or incomplete, with a log. X means discarded because the record already exists. The service reads those outcomes back and either updates HubSpot or opens a review task.

State lives in the service: a watermark per view, a queue of rows awaiting import, and a replay endpoint. The transit database sits on the same SQL Server as Business or elsewhere on the company network, so the service runs where it can reach it.

What decides the route here is whether anything has to flow back into Business, not how many objects you want to see.

If HubSpot only needs to show customers, items, orders and invoices, the transit database’s views are already flat, and managed sync on Skyvia can read them one way once it can reach your SQL Server. That is the lightest build.

Once leads or won deals have to reach Business, every write needs its import status read back and its errors handled, which is logic a service we build keeps in one place. We steer away from a general automation platform: it needs a way into your SQL Server and pays for each write twice. Business’s own import and export module writes files from saved profiles, which suits a one time migration better than a daily sync.

1. Scope. The first call includes your NTS partner. We confirm the Business version, the companies in scope, the CRM module and which customers and items are flagged for outside applications.
2. Architect. We fix the keys, the watermark per view, the external code scheme and the handling for each import status, and write the mapping in English.
3. Build. The service is written against a test company’s transit database, with a login scoped to the views and tables it needs and a portal allowlist from the first commit.
4. Validate. We reload customers, orders and sales documents into a HubSpot sandbox, reconcile counts and totals, and push test leads through the scheduled import.
5. Operate. We watch the queue of rows awaiting import, keep the replay endpoint ready, and re-check the views after every Business update.