A sales rep in the North team opens a deal that belongs to the South team. Nobody gave them access, their role says "Their team's deals", and yet there it is. The same week, a new rep complains that half the leads assigned to them after a migration simply do not appear in their views. Two opposite problems, one portal, and the roles look correct in both cases.
This is the pattern we see most often when we review HubSpot portals for B2B teams. HubSpot is doing exactly what it was told. The problem is that most of what it was told does not live in Users & Teams at all.
Roles rarely change. Record data changes every day, and access changes with it.
Why HubSpot Permissions Look Right but Behave Wrong
HubSpot user permissions work in two layers. The role (or the individual permission set) decides the type of access a user gets: All records, their team's records, their own records, or none. The record itself decides which records fall into each bucket, based on who is named in its owner fields, which team it belongs to, who it has been shared with and which pipeline it sits in.
Most permission reviews only look at the first layer. They open each role, confirm the settings, and sign it off. But a role that says "Their deals" can still expose a record to ten people if the record data says ten people own it. That is why HubSpot's own user permissions guide ties ownership access to owner properties, not just to the role.
Want a clear view of who owns which records across every team?
Explore HubSpot CRM DashboardsHow Data Gets Exposed
Custom user properties create extra owners
"Owned only" does not mean "the record owner only". HubSpot calculates ownership from the default owner property and every custom property of the HubSpot user field type. Add an "Implementation Manager" or "Account Director" field to deals, and every user selected in it now has the same access as the deal owner. Nobody touched a role, yet access widened across the whole object. This is why property design belongs in any fields and validations review, not just in data quality work.
Parent teams and extra teams see more than you planned
In Enterprise accounts, teams can be nested. A parent team sees everything owned by the teams below it, while nested teams cannot see upwards. After a reorg, a team moved under the wrong parent can hand a whole region's pipeline to another manager. Extra team membership works the same way: adding someone to a second team "just for reporting" also gives them access to that team's records. HubSpot documents this behaviour in its guide to creating and managing teams.
Anyone can share records if the Shared users field allows it
Records can be shared with specific users and teams through the Shared users and Shared teams properties. If those properties are left on "Allow everyone to view and edit", any user can share any record they can edit with anyone else. Workflows can also append users to these fields automatically, which means one old automation can keep granting access long after the reason for it has gone.
Restricted fields, unrestricted copies
Field-level permissions protect a property, not the information in it. If a rep types the same salary figure or health detail into a note, or a workflow copies a restricted value into an open property, the restriction no longer covers it. Super Admins also see every property regardless of restrictions, including Sensitive Data properties, so a portal with fifteen Super Admins has fifteen people outside every field-level rule you have set.
How Data Gets Locked
The Unassigned checkbox ignores custom owner fields
When a role is set to "Their deals" or "Their team's deals", the Unassigned checkbox decides whether users can also see records with no owner. The catch: it only checks the default owner property. A record with an empty Deal owner still counts as unassigned, even if a custom user field names someone, so every user with Unassigned ticked can see it. Imports that skip the owner column do the opposite: they create hundreds of records that owned-only users without Unassigned can never find. We covered how owner mapping goes wrong during a partial import in our Insightly to HubSpot migration case study.
Owner reassignment moves the team with it
When a record's owner changes, HubSpot automatically fills the HubSpot team property with the new owner's main team. A rotation workflow or a round-robin assignment can therefore move a record out of one manager's team scope and into another's without anyone noticing. The previous manager loses access, and the report they relied on shrinks with it. Owner-rotation workflows deserve the same review as the automations behind contacts stuck in the wrong lifecycle stage.
Pipeline access and stage locks cut people out
Giving one user or team explicit access to a pipeline restricts that pipeline for everyone else. Admins often do this to protect a single sensitive pipeline and then discover that finance, support or leadership can no longer see deals they need. Stage-level edit restrictions on deals, tickets and custom objects add another layer: a user can view a deal but cannot move it past a locked stage, which looks like a bug from their side.
Object access without activity access
A user with access to contacts but not to activities can only see the contact's property data. Calls, notes and emails disappear from their view, so the record timeline looks empty. It is a sensible setting for some roles, but it is often applied by accident when a role is cloned from another one.
Changes do not apply until the user logs out
Record access permissions only take effect after the user logs out and logs back in. Admins fix a permission, the user refreshes the page, nothing changes, and the admin starts changing other settings. Several "permissions are broken" tickets end with a simple log out.
Why Reports Show Different Numbers to Different People
Record permissions also apply inside reports. A user with owned-only access sees only their own records on index pages, in segments and in reports. So a dashboard shared with the whole sales team does not show everyone the same total: the VP sees the full pipeline, while each rep sees their slice of it. Dashboard sharing controls who can open the dashboard, not which data they see inside it.
This is one reason leadership meetings end up arguing over whose number is right, a problem we unpacked in why HubSpot attribution reporting doesn't match your sales numbers. It is also why a dashboard can look complete to one person and half-empty to another, similar to what happens when CRM data looks clean but isn't.
The HubSpot Permission Leak & Lock Matrix
Use this table to go from symptom to cause. Each row maps a problem users report to the setting that usually creates it and where to fix it.
| Symptom users report | Hidden cause | Fix |
|---|---|---|
| ExposedUsers see data they should not | ||
| Rep sees deals they do not own | Named in a custom HubSpot user property | Audit user-type properties per object Where: Settings > Properties, filter by field type |
| Manager sees another region's pipeline | Team nested under the wrong parent | Redraw the team hierarchy after every reorg Where: Users & Teams > Teams |
| User sees a team's records "only for reporting" | Added as an extra team member | Use report filters instead of team membership Where: User profile > Extra teams |
| Records visible to people nobody approved | Shared users editable by all, or appended by a workflow | Restrict the Shared users property and review workflows that set it Where: Property settings, Automation > Workflows |
| Restricted data appears in notes or other fields | Values copied outside the protected property | Find workflows copying the value and set a no-notes rule Where: Workflows, team guidelines |
| LockedUsers cannot see data they need | ||
| Imported records invisible to reps | No owner mapped, Unassigned not ticked | Bulk-assign owners or tick Unassigned for the right roles Where: Record index view, role settings |
| Manager loses a record after reassignment | HubSpot team property follows the new owner's main team | Check the main team of every user in rotations Where: Record owner history, user profile |
| Whole department cannot see a pipeline | Explicit pipeline access given to one team | List every team that needs the pipeline, not just one Where: Objects > Deals > Pipelines |
| Record timeline looks empty | Object access granted without activity access | Add activity permissions to the role Where: Role > CRM permissions |
| Permission fix "does nothing" | User has not logged out since the change | Ask the user to log out and back in before retesting Where: User session |
A 30-Minute HubSpot Permissions Audit
You do not need a full rebuild to find most permission problems. Run these five checks in order, because each one changes what the next one reveals.
| Step | What to check | Red flag | Where |
|---|---|---|---|
|
1Super Admins & roles
|
Who holds Super Admin and which roles were cloned from others | More Super Admins than the account needs | Users & Teams > Users, Roles |
|
2User-type properties
|
Every custom HubSpot user field on each object | Each field is an extra owner nobody reviewed | Settings > Properties |
|
3Team tree
|
Main, extra and nested teams for every user | Teams under the wrong parent, extra teams added "for reporting" | Users & Teams > Teams |
|
4Sharing & pipelines
|
Shared users settings, pipeline access and stage locks | Sharing open to everyone, a pipeline restricted to one team | Property settings, Pipelines |
|
5Test as a real user
|
Five sensitive records from different teams | Unexpected names in the Users with access list | Record > Users with access |
The last step matters most. On any record, HubSpot can show you which users have access and why, including owners set through custom user properties. Pick five sensitive records and read that list. If a name surprises you, trace it back through the matrix above.
Permissions also need an owner after the audit. Someone has to approve new user-type properties, team moves and pipeline restrictions, or the same problems return within a quarter. Our CRM data quality framework includes a RACI model you can extend to access control, and a HubSpot CRM audit covers permissions alongside data and automation health.
Not sure who can see what in your HubSpot portal?
Book a Free ConsultationFAQ
Why can a HubSpot user see records they don't own?
The most common reasons are that they are named in a custom HubSpot user property on the record, they belong to a parent team or an extra team, or the record has been shared with them through the Shared users or Shared teams property. Owned-only permissions count all of these, not just the default owner field.
Why did a sales rep or manager lose access after the record owner changed?
When the owner changes, HubSpot updates the HubSpot team property to the new owner's main team. If the new owner sits in a different team, users with team-only access to the old team lose the record, even though their own permissions did not change.
Do HubSpot permission changes apply immediately?
Not for the user who is already logged in. Record access permissions take effect after the user logs out and logs back in, so always ask them to do that before testing whether a fix worked.
Does the Unassigned checkbox include custom owner properties?
No. The Unassigned option only looks at the default owner property for the object, such as Deal owner. Custom HubSpot user properties are ignored for that setting, even though they do count towards owned-only access.
Can field-level permissions stop sensitive data from leaking in HubSpot?
They protect the property, not copies of its value. Data typed into notes or copied into other properties by workflows is not covered, and Super Admins can see every property. Combine field-level permissions with a small Super Admin list and a review of any workflow that copies restricted values.
Leave a comment