Last updated: August 2026. Refreshed quarterly as HubSpot ships new features and updates its documentation. If you’re reading this more than a few months after this date, check the linked HubSpot documentation for current details.
Quick Answer
HubSpot’s documentation is generally accurate, but it’s organized around individual features; not around the questions admins actually ask when something goes wrong. This piece collects the gaps that show up repeatedly in HubSpot’s own community forums: export permissions that don’t behave the way the settings page implies, a free-plan retention change that quietly hid years of activity history, audit log features that exist but don’t cover the surface area you’d expect, and a couple of 2026-specific changes worth knowing about if you haven’t checked your settings recently.
This piece is different from our other guides. Rather than a single deep dive, it’s a running list of specific, sourced gaps between what HubSpot’s documentation says (or doesn’t say) and what admins discover in practice. Usually in a community forum thread, usually after something didn’t work the way they expected. Each entry below is something that isn’t necessarily wrong in HubSpot’s docs, but isn’t surfaced clearly either until you hit it.
We’ll add to this list and refresh the date each quarter. If you’re working through our Complete Guide to HubSpot Data Protection, think of this as the “known issues” appendix; the specific, dated details that supplement that guide’s broader framework.
HubSpot’s Users & Teams settings include a toggle called “Export,” under CRM Tools, that controls whether a user can export contacts, companies, and deals. Turn it off for a user, and they lose the ability to export those three object types. Straightforward enough, except for what it doesn’t cover.
It doesn’t extend to marketing content. A HubSpot team member confirmed directly in the community: the Export toggle governs CRM record exports specifically, but there’s no equivalent control for exporting marketing assets. Email recipient lists, landing pages, and similar content remain exportable regardless of how the CRM Export toggle is set. If your organization’s data protection concern is “we don’t want certain users pulling lists of people out of HubSpot,” turning off Export for CRM objects may not close the gap you think it closes if those same users have access to marketing tools.
Export approvals and large-export alerts may not apply to reports. In a detailed community thread, an admin systematically tested HubSpot’s export approval and large-export-notification features, both designed to flag or require sign-off for bulk data exports, and found that exporting a report with 900 records triggered neither the approval workflow nor the large-export notification, despite the export appearing correctly in the audit log afterward. The data was logged; the alerting wasn’t triggered. If your organization is relying on these notification features as a control (as recommended in our Complete Guide’s visibility section), it’s worth specifically testing whether report exports actually trigger them in your account, rather than assuming parity.
The practical takeaway: “Export” as a single permission toggle suggests a single, comprehensive control. In practice, it’s scoped to specific object types and specific export paths. If data exfiltration is part of your threat model, test the actual boundaries of what “Export off” means in your account, rather than relying on the name of the setting. Per our backup guide’s ransomware research, data exfiltration should increasingly be part of your threat model.
In late 2024, HubSpot updated its Free plan to limit visible activity history (calls, emails, notes, tasks) to the most recent 30 days. This wasn't announced as prominently as a feature launch typically would be, and the community thread responding to it makes the practical impact clear: customers with years of CRM activity history on the Free plan suddenly found that history inaccessible through the standard UI, not just for new activity going forward, but retroactively for everything already in the account.
The genuinely important detail, confirmed by HubSpot directly in that thread: the activities themselves aren't deleted. They're hidden from the UI on the Free plan specifically. Upgrading to a paid tier (Sales Hub Starter and above) restores visibility into the full history immediately. Nothing needs to be re-imported or recovered, because nothing was actually removed.
Why this belongs in a data protection guide, even though nothing is technically "lost": this is a sharp illustration of the gap between "the data exists" and "the data is accessible to you in a way that's useful." An organization on the Free plan that needs to reference activity history older than 30 days, whether for a customer dispute, an audit, or simply understanding a long-running account relationship, would, without knowing about this change, reasonably conclude the data is gone. It isn't. But "isn't gone, but also isn't visible, and the UI gives no indication that hidden-but-present data exists" is exactly the kind of distinction that doesn't show up until you need it.
If your organization is on HubSpot's Free plan and any part of your data protection or compliance posture depends on being able to access historical activity records, this is worth confirming directly. It's also worth noting as a reason a basic export-based backup (capturing activity data while it's still under 30 days old, on a rolling basis) has value even on the Free plan, independent of anything covered in our main backup guide.
Our Complete Guide's access control section covers the Enterprise-gating of permission sets generally. A more specific point surfaced in the community deserves its own entry: an admin asked specifically about creating reusable permission templates, set up once and applied to multiple users, versus the alternative of either using HubSpot's built-in preset roles or manually copying permissions from an existing user, one user at a time.
The answer, from an experienced community contributor: custom, reusable permission sets exist only on Enterprise tiers. On Professional, the choice is between HubSpot's built-in presets (which may not map precisely to your org's roles) or the manual "copy from an existing user" approach, which works, but doesn't scale, and is easy to let drift out of sync as the "template" user's permissions change over time without every copy being updated.
Why this matters specifically for data protection: Section 2 of our Complete Guide emphasized building roles around what people actually do, rather than around convenience. But on Professional, the infrastructure for doing that at scale (reusable, centrally-updatable role definitions) isn't available. An organization on Professional that wants role-based access control has to either accept the built-in presets, accept the drift risk of manual copying, or treat "upgrade to Enterprise" as part of the cost of a more rigorous access control posture. That's worth knowing explicitly when weighing subscription tier against data protection requirements, rather than discovering it mid-implementation.
You may encounter both terms, "Permission Sets" and "Roles," used somewhat interchangeably in HubSpot community discussions and third-party guides, with some sources describing a renaming from one to the other. We want to flag this rather than assert it definitively: HubSpot's own current documentation (as of this writing) primarily uses "Permission Sets" as the feature name in Settings > Users & Teams. If you encounter a "Roles" tab or terminology in your account, the underlying concept is the same regardless of which label your account currently shows: predefined, reusable permission bundles, Enterprise-tier. If you're working from third-party documentation that references one term and your account shows the other, that's a naming/UI variation, not a sign you're looking at a different feature.
HubSpot has announced that legacy CRM cards built with the older CRM Extensions API will stop rendering on HubSpot CRM records as of October 31, 2026. This deprecation was originally announced in May 2025, with the final cutoff communicated again in HubSpot's May 2026 developer changelog.
This is squarely a "data protection" issue in the sense that matters for this guide. If your organization has older integrations that surface external data inside HubSpot records via legacy CRM cards, such as a support ticket system, a billing platform, or a custom internal tool, those cards will simply stop appearing on October 31, 2026, unless migrated to the current CRM Extensions framework before then. The data in the external system isn't affected. But if anyone on your team has come to rely on seeing that information inside HubSpot, as part of, say, a workflow for checking customer status before taking an action, the disappearance of that card is the kind of "nothing was deleted, but something that used to work no longer does" change that's easy to miss until someone notices a card is gone and doesn't immediately know why.
If your organization has any custom-built or older third-party integrations that add cards to HubSpot CRM records, this is worth a specific check before the October 2026 deadline. Test migrated cards in a developer/sandbox account, as HubSpot's own guidance recommends, rather than discovering the gap on the day the legacy cards stop rendering in production.
A smaller item, but a genuinely useful one for any organization with strict network configurations: HubSpot now offers webhook notifications (in addition to existing email notifications for account admins) when HubSpot's published IP ranges change, whether they are added, modified, or removed.
If your organization has firewall rules, allowlists, or network configurations that reference HubSpot's IP ranges, which is common for organizations that have configured strict outbound/inbound rules around their HubSpot integration, an IP range change that isn't reflected in your firewall configuration could silently break connectivity between your systems and HubSpot. This isn't a "data loss" scenario in the sense of the rest of this guide, but it's exactly the kind of "everything was configured correctly until an upstream change wasn't accounted for" issue that fits this piece's theme. If this applies to your organization, registering for these notifications (via the IP Ranges API) is a low-effort way to stay ahead of a change that could otherwise surface as "why did our integration just stop working."
This list is intentionally not exhaustive. It's a living document, refreshed quarterly. If you've hit a HubSpot behavior that wasn't clearly documented and that affects how your organization thinks about data protection, access, or recovery, we'd genuinely like to hear about it for future updates to this piece.
Related Guides