HubSpot + Jobscope integration

An engineer-to-order manufacturer lives or dies on the estimate. Jobscope’s estimating system prices items that have never been built, one bid can carry several proposals, and the order that follows can split into several jobs, each with its own releases. All of it sits in Jobscope, which its developer has sold to job-based manufacturers since the company was founded in Greenville, South Carolina, in 1980. The people selling the next job work somewhere else.

What they cannot see decides their next conversation. Jobscope tracks every job against a sales budget and a current budget by cost category, projects an estimate at completion, and bills progress payments with retainage. An account manager calling a customer about new work wants to know which estimates are still open, which contracts are running over budget and which progress bills are outstanding. Today that means asking the controller for an export.

Jobscope has a CRM module of its own, with accounts, contacts, activities and quote probabilities, so some firms never need a second system. HubSpot enters when the website, the forms and the email sequences already live there, and when an engineer-to-order sales cycle runs long enough that the pipeline has to sit where the sales team will actually open it.

Five objects carry the pursuit and what follows it. Each Jobscope customer becomes a HubSpot company, with its people as contacts. Estimates become deals, because an estimate is the record that is won or lost. Jobs and their invoices go to custom objects, each associated with its company and its deal.

Everything moves one way, into HubSpot. Jobscope is the system of record for price, cost and billing, and a CRM that can edit a job budget is a liability.

The keys need care on two counts. A contract can hold several jobs and a job several releases, so the job number is the key and the order never is. And Jobscope supports multi-company and multi-division processing, while its public pages do not say whether numbers repeat across companies, so every key carries its company from the first run. Job cost travels as properties on the job: the current budget, the actual cost to date and the estimate at completion, which is the figure an account manager actually asks about.

The runtime is a managed sync over SQL, the house pattern for a system with no public API. Jobscope is built on Microsoft SQL Server, and Jobscope documents reporting tools reading that database directly. We write read-only views over the tables each object needs, one view per object, and a Skyvia package reads each view on a nightly schedule.

Skyvia reaches an on-premises SQL Server in one of two ways: directly, which needs the server reachable from the internet, or through its agent, a small application inside your network that needs no dedicated external IP or port. Each package upserts into HubSpot by looking the record up on the custom property that holds its Jobscope key, so a rerun updates rather than duplicates. The packages run as a chain, companies first, then contacts, deals, jobs and invoices, so every parent exists before its children. State is the key on each HubSpot record, and a replay is simply the chain run again.

What decides the route here is who controls the database. If Jobscope runs on your own servers, a managed sync over read-only views is the cheapest route that carries every object above. If Jobscope hosts it under its managed cloud subscription, the same sync needs Jobscope’s agreement to the agent or to a firewall rule, and that conversation comes before any mapping.

Then ask whether anything must travel back into Jobscope. A managed sync reads; it does not create jobs. When a won deal must open the job in Jobscope, the write belongs to Jobscope’s API offering or its integration developers, and a custom API integration is built to whatever Jobscope agrees. A general purpose iPaaS adds little here: it needs the same database access and bills per task.

1. Scope. We confirm the edition, who hosts the database and whether anything must flow back, then list the objects the sales team will open.
2. Architect. We write the view contract: columns, keys scoped by company, the load order and the nightly schedule, agreed with whoever holds the schema.
3. Build. Views and packages are built against a copy of the database where one exists, and against a HubSpot sandbox behind a portal allowlist.
4. Validate. We reconcile row counts per view and compare open estimate and job totals with a Jobscope report before cutover.
5. Operate. Cutover points the packages at production. After that we review each run’s counts, rerun from any failed package, and recheck the view contract when Jobscope ships an upgrade.