A HubSpot subscription tells you what happened inside HubSpot. A 6sense subscription tells you which accounts are showing intent signals somewhere else on the web. Neither tool on its own tells a RevOps lead which accounts are worth a call this week. Building a merged dashboard with n8n as the connective layer solves a specific problem: turning two separate systems of record into one queryable dataset that a sales or marketing team can act on without logging into either platform. This post works through the mechanics of doing that, including where the native integration between HubSpot and 6sense is good enough on its own and where it stops being sufficient.
Why HubSpot, 6sense and n8n Together Beat a Single Platform Dashboard
HubSpot’s reporting engine is good at describing activity that happens inside HubSpot: form fills, email opens, deal stage changes, meeting bookings. It has no visibility into a prospect reading a competitor comparison page on a third party review site, or a buying committee researching a category across the wider web. That is the gap 6sense is built to close: it scores accounts on intent signals gathered outside your own domain and surfaces which accounts are actively in market before they have filled in a form.
6sense already ships a native HubSpot integration that writes intent scores and stage predictions back into HubSpot properties, and for many teams that is sufficient. It needs no custom code, it inherits HubSpot’s existing permission model, and it keeps everything inside one interface for reps. The limitation shows up once you want to do anything beyond what the native mapping supports: joining intent data against fields that live outside HubSpot, blending in a third data source such as product usage, or writing the combined dataset somewhere a BI tool can query directly rather than through HubSpot’s own reporting limits. n8n exists to remove that ceiling. It sits between the two platforms, and any others added later, pulls data from each on its own schedule, joins and reshapes it, and writes the result to a store built for reporting rather than for CRM transactions.
The tradeoff is engineering effort. A native field sync takes an afternoon to configure. An n8n based pipeline takes longer to build and needs someone to own error handling, schema changes and credential rotation over time. For a small team running one or two intent-based plays, the native sync is usually the right starting point. For a RevOps function that wants a single warehouse feeding finance, customer success and sales from the same account level data, the orchestration layer earns its cost once the first cross-system report is needed.
Preparing HubSpot and 6sense Before You Touch n8n
Before any workflow is built, decide on the join key. Domain is the obvious candidate because both platforms track it, but it fails in predictable ways: a company with regional subsidiaries might have deals logged against a country-specific domain in HubSpot while 6sense scores intent against the parent group’s domain. Build a small mapping table for known exceptions rather than assuming domain matching will be clean from day one, since this is far cheaper to maintain than debugging silent join failures downstream.
In HubSpot, create a dedicated private app rather than reusing a personal API key. Private apps let you scope access precisely, granting read only access on contacts, companies and deals for example, and revoking one when a contractor’s engagement ends does not break every other integration on the account. HubSpot’s developer documentation covers current scopes and rate limits for private apps and is a sensible check before requesting access, since limits and endpoints change between API versions.
On the 6sense side, confirm which segments and models actually feed the account and buying stage data you plan to pull, because a model built for one product line will not necessarily reflect intent for another. Agree with whoever owns the 6sense instance on a fixed list of fields you need, such as account score, predicted stage and top intent topics, rather than pulling every available attribute. An unbounded pull is far more likely to break when 6sense’s schema changes as models are retrained.
Store both sets of credentials in n8n’s credential manager rather than inside individual workflow nodes as plain text. Data flowing between systems still counts as processing personal data under UK GDPR, so the usual accountability and minimisation principles apply even though the interface is an API call rather than a form. The ICO’s guidance for organisations is a reasonable starting reference if your data protection lead has not already covered API-level integrations specifically.
Designing the n8n Workflow That Keeps Data in Sync
A workflow that survives contact with production traffic follows a predictable shape: trigger, extract, join, standardise, load, with a separate branch for failure. In n8n that maps to a Schedule Trigger node, two HTTP Request nodes (one against the HubSpot API, one against the 6sense API), a Set node that normalises the join field, a Merge node that combines the two datasets on that field, a second Set node that renames and standardises the remaining fields, and a final node that writes the result somewhere durable.
Pagination is the first thing that trips people up. HubSpot’s list and search endpoints return a fixed page size with a cursor for the next page; a workflow that only pulls the first page looks correct in testing, where test accounts have a handful of records, and then drops most of production data once the account has thousands of contacts, without any error being thrown. Build the pagination loop from the start, using n8n’s Split In Batches node or a loop back to the HTTP Request node until no further cursor is returned, rather than adding it once someone notices the dashboard undercounting deals.
Choose polling over webhooks for this pipeline unless there is a strong reason not to. 6sense does not expose the kind of granular event stream that would make real-time updates meaningful for account scoring, since scores move slowly compared with something like a form submission, and a scheduled pull every few hours is close enough to real time for a dashboard people check once or twice a day. Webhooks earn their complexity when an action needs to fire within seconds of an event; for a dashboard read periodically by a human, maintaining webhook endpoints and handling events missed during downtime rarely pays for itself.
The join needs a normalisation step before it, not just a straight field match. Lowercase both domain fields, strip protocol prefixes and trailing slashes, and remove a leading “www.” so that different formats of the same domain resolve to one key. Do this in a Set node immediately before the Merge node, so the normalisation logic lives in one visible place rather than being buried inside a Function node further down the workflow.
Error handling deserves its own branch, not an afterthought bolted onto the main flow. Configure a separate n8n error workflow, triggered automatically when any node in the main workflow fails, that posts to a Slack channel with the failed node’s name and the data that caused it. This turns a silent gap in the dashboard, a missing day of data nobody notices for a week, into an alert within minutes. n8n’s documentation covers how error workflows attach to a parent workflow, and setting this up before the first production run saves retrofitting it after the first failure.
Finally, write to a datastore built for querying, not to a spreadsheet or directly into a BI tool’s proprietary storage. A small Postgres instance that the workflow upserts into, keyed on a stable record ID rather than appended to on every run, avoids duplicate rows when a workflow is manually re-triggered after a failure. Upsert logic, inserting on a new ID and updating on an existing one, is a few extra minutes of configuration and prevents a class of duplicate-counting bug that is otherwise painful to trace back to its source.
Turning Synced Data into a Dashboard People Will Use
Once data lands in Postgres, the choice of visualisation tool matters less than how the underlying fields are structured. Looker Studio, Power BI and Tableau can all connect to a Postgres source, and each will produce a broadly similar dashboard from the same clean tables. The value comes from calculating metrics once, in the workflow or the database, rather than letting each dashboard author redefine what counts as an engaged account or qualified pipeline slightly differently in their own tool. A calculated field for account engagement percentile that lives in the database means every dashboard built on top of it agrees with every other one.
Design for the audience reading the dashboard rather than for one generic view. An executive dashboard needs a handful of numbers: pipeline coverage against target, forecast confidence banding, and stalled deal count. A demand generation manager needs channel level attribution and intent trend over time for their target segments. A sales manager needs account level detail, such as which named accounts in their patch have a rising intent score with no open deal. A single dashboard that tries to serve all three audiences tends to serve none of them well, because the executive view gets cluttered with account level detail nobody at that level needs, and the rep level view gets buried under summary charts nobody at that level reads.
Align the BI tool’s refresh schedule with the n8n workflow’s schedule, not the other way round. If the workflow pulls data every six hours, setting the BI tool to refresh every fifteen minutes achieves nothing except extra load on the database. If the workflow runs nightly, a dashboard that claims to refresh hourly misleads anyone who checks it mid afternoon expecting new numbers.
Common Failure Modes and How to Guard Against Them
Rate limiting is the most common early failure. HubSpot enforces request limits per app within a short time window, and a workflow that fires HTTP Request nodes inside a loop without any throttling will eventually hit that ceiling as contact volume grows, returning 429 errors that truncate a data pull if they are not caught. Add a short delay between paginated requests and treat a 429 response as a retryable error with backoff, rather than a fatal failure that stops the whole run.
Schema drift is the second failure mode. Someone renames a HubSpot property, or a 6sense model is rebuilt with a different set of intent topic labels, and the workflow keeps running without erroring, writing null or mismatched values into what still looks like a healthy dashboard. Add a validation step after each HTTP Request node that checks for the presence of the specific fields the workflow depends on, and fail loudly, triggering the Slack alert branch, if an expected field is missing rather than passing through a null.
Partial failures are the hardest to catch because the dashboard still shows numbers, just wrong ones. A batch of five hundred contacts where most import cleanly and a handful fail validation will not look broken at a glance; it looks like a dashboard with slightly low numbers. Log a record count from each stage of the workflow (records pulled from HubSpot, records after the join, records written to Postgres) and compare them automatically, flagging any run where the drop off between stages exceeds a small tolerance.
Validation checks like these are one of the mechanisms that tend to drive down sync error rates across an automation programme generally. Equanax has recorded an 86 percent reduction in fixable sync errors.
Maintaining and Scaling the Workflow Over Time
Export every n8n workflow’s JSON definition into version control, the same as any other piece of infrastructure. This gives a diff when someone changes a node’s configuration, a rollback path when a change breaks production, and a record of who changed what and when, which matters once more than one person maintains the pipeline.
Keep a lightweight data dictionary alongside the workflow: for every field in the output table, note which system it came from, what transformation was applied, and who owns the definition. A shared spreadsheet with one row per field is enough, and it typically saves more onboarding time than any other artefact in the project when a new team member asks why a number does not match what they see in HubSpot directly.
When extending the pipeline to a new function, such as pulling billing data from Stripe for finance or product usage events for customer success, add new HTTP Request and Merge nodes onto the existing spine rather than duplicating the whole workflow. Each new source should join against the same domain or account key already established, so a single account level table keeps growing wider instead of fragmenting into several dashboards that each tell a partial story.
Run a periodic sample check regardless of how mature the pipeline becomes: pull ten to twenty records at random from the output table and manually compare each field against the source system. Automated validation catches missing fields and failed requests, but it will not catch a mapping that was wrong from the start, such as a field labelled deal owner that in practice contains the deal creator, and only a manual spot check surfaces that kind of error.
Related Reading
For more on this, see the full HubSpot archive, including Discover the Best Free HubSpot Tools for Your Business, HubSpot & RealPage Case Study: SaaS Email Automation for Revenue and Retention, and Seamless Stripe-HubSpot Integration for FinTech Teams with N8N.
Frequently Asked Questions
Should we use 6sense’s native HubSpot integration instead of building this in n8n?
Use the native integration if you only need intent scores written into HubSpot properties for reps to see. Build the n8n pipeline once you need to join that data against non-HubSpot fields, add a third data source, or feed a BI tool that queries a warehouse directly rather than HubSpot’s own reporting.
How often should the workflow refresh?
Match the refresh cadence to how the dashboard is actually read. A pull every few hours is usually close enough for account intent scores, which move slowly, and there is little value in polling more often than the dashboard’s audience checks it.
What causes join failures between HubSpot and 6sense records?
The most common cause is domain formatting: differences like a protocol prefix, a trailing slash, or a www subdomain being present in one system and not the other. Normalise both domain fields (lowercase, strip protocol and www) before the join, and keep a manual mapping table for known exceptions such as subsidiaries using a different domain to their parent group.
How do we avoid duplicate records when a failed run is re-triggered?
Write to the destination table using an upsert keyed on a stable record ID rather than appending every run. This means updating an existing row when the ID already exists, and inserting a new one only when it does not, so re-running a failed workflow after a fix does not create duplicate rows.
Leave a Reply