HubSpot Permissions: Design Access by Role, Not by Person

Most HubSpot portals I review do not have an access design. They have an access history. Someone needed a report, so they got a toggle. A new manager had to fix a workflow, so they became an administrator. A year later, nobody can explain why a sales rep sees another country’s deals, and nobody is sure the person who left last quarter has really lost access.

That works while one team uses the portal. It breaks the day a second team, a new market or a wave of hires arrives. Then the choice is: keep granting access person by person, or define a few roles once and put people into them. This guide shows the second approach in four layers.

What’s happening: access grows by exception

In HubSpot, what a person can do is not one setting. It combines their permissions, their team, any restricted assets and their seat (the license type). Each is usually changed for a good local reason; nobody looks at the combination. The same patterns appear in small and large portals:

• Too many Super Admins. A Super Admin is an account-wide administrator who can change almost anything, including other people’s access. HubSpot’s user permissions guide notes that only a Super Admin can make another user a Super Admin. In practice, each admin promotes the next and nobody is ever demoted.
• Individual toggles. Permissions edited user by user, so two people with the same job have slightly different access and nobody knows which one is right.
• Forgotten visibility rules. A “team only” setting that someone applied years ago, and users who belong to no team at all.
• Inactive accounts. People who have not logged in for months but still hold access, records and sometimes a paid seat.

Connected apps also act inside the portal with their own permissions, often tied to a named user. That side is covered in assigning owners to connected apps; this article focuses on people.

Why it matters

Access drift rarely causes one big incident. It causes three recurring problems that look like something else.

People see the wrong records. A rep in one country can open another country’s deals, or after a reorganization a manager can no longer see their own team’s pipeline. It gets reported as a bug, but the cause is almost always a team assignment combined with a visibility rule.

Leavers keep working in the system. A deactivated user can still own open deals, still appear as a filter in workflows and still be bookable. HubSpot’s guide to deactivating and removing users states that if a scheduling page or meeting rotation is not reassigned, meetings will continue to be booked for the deactivated person, and they will not be notified.

A seat change removes tools without changing permissions. HubSpot’s seat management guide is explicit: changing a user’s seat does not automatically change their permissions. Move someone from a Sales seat to a Core seat and they lose some Sales Hub features while their permission set stays exactly as it was. What they can actually do is, in HubSpot’s words, “the maximum access allowed based on the combination” of the permission set and the seat. In the users list, each assigned permission set now shows a Full or Partial label next to it. HubSpot does not document what the label measures, so treat a Partial as a prompt, not a diagnosis: after a seat change, open that user and check what they can still do.

What to do: design access in four layers

Each layer answers one question. Permission sets: what may this role do? Teams: whose records does it see? Asset access: which shared lists, workflows and reports can it touch? Seats: which tools can it open? Kept separate, each layer is easy to explain.

1. Permission sets: start from roles, not people

A permission set is a saved bundle of permissions that you assign to users instead of ticking boxes for each person. According to HubSpot’s permission sets documentation, they require an Enterprise subscription, you can create up to 100 of them, and assigning a set overrides the individual’s existing permissions. Only a Super Admin can create or edit them.

Permission sets live in Settings under Users & Teams. The limit is not the useful number. Aim for five to eight sets, each named after a job people recognize. If you cannot name the sets your portal runs on, every onboarding is a one-off decision and every offboarding is a guess.

On one multi-country portal I worked on, agreeing the roles before touching individual users is what made a later seat change checkable: you review a handful of roles, not every user one by one.

Treat Super Admin as a status, not a role. Keep a short, named list (two or three people), each with a reason. Without Enterprise you cannot save sets, but the discipline still applies: write the roles down and apply them the same way every time.

2. Teams: decide whose records each role sees

A team in HubSpot is a group of users, and record permissions are scoped by team. For each object (contacts, companies, deals, tickets), view access can be set to “All”, “Their team’s” or “Their” (records the user owns), edit and delete access to the same three or “None”, with an extra “Unassigned” checkbox for records nobody owns yet. The permissions guide also warns that view permissions are not the same thing as a View-Only seat.

Two details from HubSpot’s teams documentation shape the design:

• Nested teams see down, not up. On Enterprise you can place a team under a parent team. The parent sees everything owned below it; the nested team does not automatically see what the parent owns.
• Extra teams give visibility, not workload. A user has one main team and, on Marketing, Sales or Service Hub Professional or Enterprise, can be an extra member of others. Extra members can access the team’s records, but they are left out of that team’s reports, routing rules and workflow rotations.

For a multi-country portal, a team usually means a country or region, nested under a parent such as “Europe”. I set this up as part of a HubSpot rollout or migration; the wider choices are in multi-country rollouts. For a single-country company, a team usually means a function: sales, marketing, service. How many teams you can create depends on your subscription.

3. Asset access: protect the shared machinery

Segments (HubSpot’s current name for lists), workflows, reports, dashboards and properties are shared tools: one careless edit affects everybody who relies on them. HubSpot lets you limit access to assets to specific users or teams. The tier varies by asset: restrictions on CRM records and custom views are available on all accounts, while workflows, reports, segments and properties need Enterprise. Super Admins can still see restricted assets.

Start with what can break other people’s work: workflows that change owners or lifecycle stages (the field that says whether a record is a lead, an opportunity or a customer), the segments they use, and leadership dashboards. If marketing works per country, the “Limit access to new content” switch (Marketing Hub or Content Hub Enterprise) makes new marketing assets visible only to their creator and the creator’s team by default.

The same layer includes individual fields. On Enterprise, you can restrict view and edit access to a property (a field on a record): private to Super Admins, view-only for everyone, or assigned to specific users and teams. HubSpot says it should not be relied on as a security measure: any user can still set a restricted property through the API (HubSpot’s programming interface, used by integrations) or when creating a record manually. Use it to prevent mistakes. If a value must stay confidential, restrict the object or tool, or keep it out of HubSpot.

4. Seats: match each role to the tools it needs

A seat is the license type that decides which HubSpot tools a user can open. The seat guide lists View-Only seats, which are free and unlimited on paid subscriptions and let people view records and reports (and log notes) without editing them; Core seats for core tools; and Sales or Service seats for the full Sales Hub or Service Hub features. Assigning or changing seats requires Super Admin or Modify billing permission.

Because seats and permissions are independent, give each permission set an expected seat and check the pair together. A read-only role on a paid seat wastes budget; a sales role on a Core seat lacks Sales Hub features and will generate support requests.

Turn joining and leaving into a routine

With the four layers in place, onboarding becomes one line: seat, permission set, main team, plus extra teams only where visibility is genuinely needed.

Offboarding needs a fixed order, because HubSpot distinguishes two steps. Deactivating is reversible: the user can no longer log in, but their profile and data stay for reporting and they remain assigned to their records. Removing is final: the profile disappears, and they are unassigned from conversations and assets and removed from reports. Before deactivating, reassign open records, remove the person from workflow filters, reassign or delete scheduling pages and rotations, remove them as a billing point of contact, and check the apps they connected. Remove the user later, once reporting no longer needs them.

Finally, check that automatic deactivation of inactive users is still on. On paid subscriptions it is on by default: each month HubSpot lists users inactive for over 90 days, notifies Super Admins and deactivates those not excluded. Review the exclusions rather than turning it off.

Illustrative worked example: three countries, 40 users

This example is illustrative, not a specific company. Imagine a business selling in France, Spain and Portugal, with 40 HubSpot users on Enterprise.

Teams: France, Spain and Portugal, each nested under a “Europe” parent so regional managers see all three. Workflows that assign owners are restricted to the two CRM admins. A single-country company would keep the same six sets and use Sales, Marketing and Service as teams instead of countries.

Onboarding line: new rep in Madrid gets a Sales seat, the “Sales rep” set and Spain as main team. They see Spanish deals and unassigned ones, and cannot open French workflows.

Offboarding line: the France sales manager leaves. Open deals and tasks go to the interim manager, the France round-robin scheduling page (the one that shares bookings across the team) is updated, workflows filtering on her as owner are corrected, she is deactivated on her last day and removed after the quarter’s reporting is closed.

If several items surprise you, start with the first two. The CRM audit checklist puts access alongside data, workflows and reporting.

Continue with the part you need

• Decide what to standardize across countries
• Give every connected app an owner
• Run a wider CRM audit