There's a question we ask every client when integrations come up that gets the most honest answers: "When a tool syncs data into HubSpot, do you know exactly what it creates, updates, or overwrites?" The answer is almost always no. Sometimes it's a confident no. More often it's a pause, followed by "I think so" or "we set that up a while ago."
That pause is the sound of integration debt. Every connected tool in your HubSpot portal is either creating clean data or generating noise, and the difference comes down to whether anyone defined the rules. Most teams connect tools during implementation, accept the default sync settings, and never revisit them. The integration works, in the sense that data moves between systems. Whether it moves correctly, into the right fields, without creating duplicates or overwriting manual corrections, is a different question entirely.
The integrations you forgot about
Pull up your connected apps in HubSpot right now. Count them. Most teams can name two or three they actively manage. The actual count is usually five to eight, and the gap between "what we use" and "what's connected" is where the problems live.
The CRM sync was set up during onboarding and runs on default bidirectional settings nobody reviewed. A former employee configured the email tool integration before they left. The form tool creates contacts on submission with its own dedup logic that doesn't match HubSpot's. And then there's the billing system integration that someone on the finance team connected to pull invoice data, running through a middleware tool that nobody on the ops team even has access to.
Each of these is syncing data on a schedule, creating or updating records based on rules that were defined once and forgotten. Some of them conflict with each other. The billing integration overwrites company name formatting that a rep corrected. The form tool creates duplicate contacts because it matches on email only while HubSpot's dedup uses email plus first name (the kind of data integrity problem that compounds over time). The CRM sync pushes a field value back into HubSpot that a workflow just updated, creating an infinite loop that nobody notices because it doesn't throw an error. It just oscillates.
This isn't a hypothetical. We see some version of it in every portal audit.
What "connected" actually means
When teams say an integration is "connected," they usually mean data is moving. But the configuration details that determine whether data moves correctly are almost never documented. And they matter enormously.
Start with sync direction. Is it one-way (source system pushes to HubSpot) or bidirectional (both systems read and write)? One-way syncs are simpler to govern because you know where the data comes from. Bidirectional syncs require conflict resolution rules: when both systems update the same field, which one wins? Most default configurations use last-write-wins, which means whichever system synced most recently determines the value. That's not a governance strategy. That's a race condition.
Field mapping is less obvious but equally important. Which fields in the source system map to which properties in HubSpot? Default mappings are designed to be permissive, not precise. An integration might map "Company Name" in the source to "Company Name" in HubSpot, but the source system stores it as "ACME INC" while HubSpot has "Acme Inc." Now you have two formatting standards competing in the same field. Or the integration maps a field that doesn't have a clean equivalent in HubSpot, so it creates a new custom property that nobody asked for and nobody maintains.
The configuration that causes the most visible damage is record creation. When the integration encounters a record in the source system that doesn't exist in HubSpot, does it create one? Under what conditions? With what required fields? Most integrations default to creating records freely, which is how you end up with contacts from test environments, internal users, and re-synced duplicates cluttering your database.
The overwrite problem
This is where the most emotional frustration lives in every integration conversation. A sales rep spends ten minutes updating a contact record. Corrects the phone number, fixes the company name, adds notes from a call. Two hours later, the integration syncs and overwrites the phone number with the old value from the source system. The rep's work is gone. They don't know why. They just know the system "changed it back."
This happens because field ownership isn't defined. Nobody decided which system owns which fields. In a well-governed integration, each field has an owner: HubSpot owns this field, the source system owns that field. Writes only flow in the direction of ownership. If HubSpot owns phone number, the integration can read it but not overwrite it. If the billing system owns invoice status, HubSpot can display it but reps can't edit it.
Without field ownership, every bidirectional sync is a tug-of-war. And the person who loses is always the rep who made a manual correction that got silently reverted.
Integration-created records you didn't expect
Beyond overwrites, integrations create records. And without creation filters, they create records you don't want.
One portal we audited had an integration that created a contact for every email address in a connected email system, including internal employees and vendor contacts. Another had a billing integration creating duplicate company records because the company name formatting didn't match HubSpot's exactly. A third had "test" contacts from a staging environment that a middleware tool pushed into production because nobody configured the environment filter.
Each of these records looks real once it's in HubSpot. It has a create date, a source, maybe some properties populated. It shows up in lists, gets included in reports, might even get enrolled in a workflow. The noise looks like signal, and if nobody's specifically monitoring for integration-created records, it contaminates the database quietly.
The safeguard is an active list that filters for integration-sourced records. HubSpot tracks original source, and most integrations have a recognizable source value. Build a list, check it weekly, and you'll catch the unexpected records before they propagate through your workflows and reports. This is a five-minute setup that most portals skip.
What breaks when an integration breaks
Here's the other question that gets a long pause: "If an integration broke tomorrow, how would you know, and how quickly could you fix it?"
The honest answer for most teams is they'd find out when someone complains. A rep notices data is stale. A report looks wrong. A workflow stops enrolling contacts that it should be enrolling. By the time the complaint reaches someone who can diagnose it, the integration has been broken for days or weeks, and the downstream impact has spread through reports, workflows, and customer-facing communications.
Integration monitoring doesn't have to be complex. A workflow-based health check works for most setups. Build an active list that filters for records created or updated by the integration in the last 24 hours. If the list is normally 50 records and drops to zero, something broke. Set up a workflow that checks the list count and sends an internal notification when it falls below a threshold. That's your canary.
For more critical integrations, document the recovery steps. Who owns the integration? What are the login credentials for the middleware tool? What's the process for re-syncing after a failure? What data might need to be manually reconciled? Most teams can't answer any of these questions until they're in the middle of a crisis, which is the worst time to figure it out.
The integration inventory you should have
Every connected tool should be documented. This sounds like overhead, and it is. It's also the minimum viable governance for a connected stack.
For each integration, document what it syncs (which objects, which fields), in which direction (one-way, bidirectional), which fields it owns (the source of truth for each mapped field), who owns the integration (the person responsible for configuration and monitoring), when it was last reviewed (the date someone actually looked at the sync settings), and what the failure process is (how you know it broke and what you do about it).
This inventory doesn't need to be fancy. A spreadsheet or a page in your internal wiki works fine. The point is that it exists, and that someone reviews it quarterly. Integrations that were appropriate during implementation may not be appropriate eighteen months later when your data model has changed, your team has changed, or the source system has been replaced.
We've walked clients through their integration inventory and found tools that were decommissioned a year ago still syncing data into HubSpot. The tool was gone, but the integration middleware was still running on the old settings, pushing stale data into live records. Nobody knew because nobody had a list of what was connected.
We audit every integration in the first phase of an engagement. Not because clients ask us to, but because the integrations they forgot about are usually creating the data problems they hired us to fix. If you're not sure what's connected to your portal or what it's doing, the diagnostic call is the fastest way to find out.
