HubSpot User Permissions: How to Set Up Roles, Teams & Access

Quick Answer: How Should You Configure HubSpot Permissions?

HubSpot permissions should be configured around how your organisation actually operates, not just job titles or default settings. Start by mapping what each role needs to view, edit, create and export, then structure HubSpot teams around record ownership, reporting and operational responsibilities. Limit administrative access, apply role-based permissions consistently and review them as your organisation changes. The goal is to give everyone the access they need to do their job without compromising data security, reporting accuracy or CRM governance.

HubSpot permissions are often configured towards the end of an implementation, with users assigned standard access based on their job titles. But those settings determine who can view, edit, export and manage information across the entire organisation.

Get them wrong, and staff can end up with access to sensitive data, the ability to change records outside their responsibilities or restrictions that prevent them from doing their jobs.

This guide is for operations, revenue and CRM leaders managing HubSpot across multiple teams, including sales, marketing, service, finance, leadership, regional offices and external contractors. We'll cover what needs to be decided before configuring permissions, how those decisions affect the wider CRM, and where organisations commonly run into trouble.

Start With Roles, Not HubSpot Permissions

The HubSpot permissions screen isn't where this process should begin. With dozens of settings across CRM, Marketing, Sales, Service and Account tabs, it's tempting to give someone broad access or select whichever standard preset looks closest to their job title.

Neither approach tells you what that person actually needs to do.

Before adding users, map the roles that will work in HubSpot and answer six questions for each:

• What do they need to see? Which records, properties and activity history are relevant to their role?

• What do they need to edit? Viewing a customer record and changing it are two different responsibilities.

• What do they need to create? Records, segments, emails, workflows or reports?

• What should they be able to export? Often overlooked, despite being one of the more significant access decisions.

• What reporting do they need? Some people work in CRM records every day. Others only need access to dashboards.

• What administration do they actually require? Not what might be useful occasionally, but what their role genuinely needs.

From there, build a simple access matrix with roles down one side and capabilities across the top. That becomes the reference point for configuring HubSpot.

The permissions settings should reflect decisions you've already made about how the organisation operates, not be the place where those decisions happen.

Map HubSpot CRM Permissions Across the Whole Customer Relationship

HubSpot doesn't treat access as one universal setting. Permissions are configured by object and action, with different levels of visibility available.

For contacts, companies, deals, tickets and custom objects, you can control view, edit and delete access separately. Depending on the object and permissions available, users can be given access to all records, records owned by their team, or records they own themselves, with options to include unassigned records. A separate Communicate permission determines which records users can log emails, calls and meetings against.

That level of control matters because an established HubSpot account usually holds far more than basic customer information.

It might include:

• Contact and company records
• Deals, quotes and line items, including pricing and discounts
• Tickets and service history
• Custom objects, including subscriptions, memberships, contracts or assets
• Invoices, payments and financial information connected to sales activity
• Marketing engagement and website activity
• Reports and dashboards

Different teams need different combinations of that information.

A service lead needs detailed ticket access and enough customer information to understand the relationship, but probably doesn't need to edit deals. Finance may need visibility across deals and invoices without changing sales records. Marketing needs access to contact information for segmentation, but doesn't necessarily need control over the sales pipeline.

This is why we recommend mapping permissions by object and responsibility rather than configuring each user individually and hoping the settings remain consistent.

Configure HubSpot Teams Around How You Operate

HubSpot teams influence three important parts of the CRM. They determine record visibility through team-based permissions, support reporting by team, and help route work such as conversations, tickets and record assignments.

That makes team structure an operational decision, not simply a way to recreate your organisation chart.

There are a few HubSpot mechanics worth understanding:

• Main and extra teams. Each user has a main team and can belong to additional teams. Extra team membership can extend their visibility under team-based permissions.

• Record ownership and reporting. HubSpot uses the record owner's main team to populate the HubSpot team property. If your main teams don't reflect how the business operates, your team reporting can become misleading.

• Nested teams on Enterprise. Enterprise accounts can create team hierarchies. Parent teams can access records owned by teams beneath them, while nested teams don't automatically receive access to records owned by their parent team.

Instead of starting with a list of departments, ask where visibility needs to stop, where reporting needs to be separated, and how work needs to move between teams.

Those answers should determine the structure.

Configure HubSpot User Permissions by Role

Once you've mapped the roles and defined the teams, configuring permissions becomes much more straightforward. You're working from a clear set of requirements rather than deciding access one user at a time.

Here's what that might look like across a typical organisation.

Sales or Account Manager

Access to the deals, contacts and companies they or their team manage, with Communicate permissions for those records. Visibility into other teams' information where handovers or shared accounts require it. No need to change property settings or workflows.

Marketing Manager

Broad visibility of contacts and companies for segmentation, alongside access to segments, campaigns, emails and engagement data. Editing rights for the marketing properties they're responsible for. Generally no need for system administration or deal editing.

Service Lead

Full access to relevant tickets and inboxes, with contact and company records available for context. Editing rights for service-related information and reporting access focused on service performance rather than the wider sales pipeline.

Finance

Visibility across relevant deals, quotes and invoices, with limited editing rights for finance-owned information. Export permissions should be considered carefully, particularly where reconciliation or external reporting requires data to leave HubSpot.

Executive

Access to dashboards and the CRM information needed to understand business performance. Most executives don't need configuration permissions, and providing unrestricted access simply because someone is senior creates unnecessary risk. HubSpot also distinguishes between View permissions and View-only Seats, which is worth considering when deciding how leadership will use the platform.

HubSpot Administrator

Broader access to manage properties, workflows, integrations, users and account settings. This role is responsible for maintaining the CRM's structure, so the additional access is justified. It shouldn't be given to someone simply because they occasionally need to change a setting.

On Enterprise, saved permission sets make this easier to manage. You can define permissions for each role and apply them consistently, rather than rebuilding the same settings every time someone joins.

Be Deliberate About Who Can Change the CRM Architecture

There's a significant difference between updating a contact record and making changes to how HubSpot operates.

Consider the difference between editing a customer record and:

• Creating or changing properties
• Building or modifying workflows
• Connecting or changing integrations
• Updating account-level settings

One affects an individual record. The others can affect thousands of records, multiple teams and entire business processes.

Most HubSpot accounts don't become difficult to manage because of one major mistake. It's usually the accumulation of smaller changes.

Someone creates a new property because they can't find an existing one. A workflow is adjusted to solve an immediate problem without checking what else relies on it. An integration is connected for a short-term project and never removed.

Individually, those decisions can seem reasonable. Over time, they create duplicated information, conflicting automation and reporting that nobody completely trusts.

HubSpot provides separate controls for property settings, workflows and account administration, so these responsibilities can sit with the people managing the CRM architecture.

On Enterprise, you can also nfigfor specific users and teams. This is particularly useful for commercially sensitive information such as margins, contract terms or internal classifications.

There is an important limitation: HubSpot notes that restricted properties can still be populated through the API or when a user manually creates a record. Property restrictions should therefore work alongside object-level permissions, rather than replace them.

The aim isn't to make every change difficult. It's to make sure changes that affect the wider business are properly considered.

Super Admin Should Be a Responsibility, Not a Convenience

Super Admin is the highest level of access in HubSpot. Someone with this permission can manage users, settings, permissions and data across the entire account. Property-level restrictions don't apply to them either.

That makes Super Admin access something to manage carefully.

In practice:

• Keep the number appropriate to the organisation. There's no universal number, but everyone with Super Admin access should have a clear reason for needing it.
  

• Document who has access and why. You should know exactly who can make account-wide changes.

• Review access when responsibilities change. Temporary project access has a habit of becoming permanent.

• Don't use it to work around poor permissions. If someone needs Super Admin access to perform an ordinary part of their job, it's worth reviewing how their role has been configured.

Treat Exports and Bulk Actions as High-Impact HubSpot Access Controls

There's a difference between someone viewing a customer record in HubSpot and exporting 30,000 records into a spreadsheet.

Once that information leaves the CRM, HubSpot's permissions no longer control how the exported copy is accessed or shared.

HubSpot provides separate permissions for several actions that can affect large amounts of data:

• Export: Controls the ability to export data. Some accounts also support Export without approval and Approve exports, allowing exports to go through an approval process.
• Import: Allows users to create or update records in bulk.
• Bulk delete: Controls the removal of multiple records from index pages and segments.
• Edit associations: Controls changes to relationships between CRM records.

These permissions deserve more consideration than simply asking whether someone needs access to contacts or companies.

Give people the information and capabilities their roles require, but make deliberate decisions about who can move, overwrite or delete large amounts of data.

This is also where your organisation's privacy and data governance obligations need to be considered. HubSpot permissions can support those requirements, but they don't automatically satisfy them.

How Should Regional Teams, Branches and Chapters Be Handled?

Organisations operating across multiple locations often need a more considered permissions structure.

A franchise network, a business with offices in New Zealand and Australia, or a membership association with regional chapters may all have the same challenge: local teams need to manage their own relationships without necessarily having access to every record nationally.

A regional manager might need full visibility across their territory, while the national leadership team needs reporting across the entire organisation.

HubSpot's team-based permissions, along with nested teams on Enterprise, can support this structure.

But the setup depends on record ownership and team design reflecting how those regions operate.

This is particularly important during implementation.

If thousands of records are imported without considering regional ownership, introducing regional permissions later can mean reassigning records, changing reports and restructuring teams.

It's much easier to address these requirements while designing the CRM than to rebuild the structure after everyone is using it.

For associations, where regional chapters may operate differently from the national office, this is one of the first things we look at when configuring HubSpot for membership organisations.

External Contractors Shouldn't Inherit Internal-Level Access

External contractors often need access to HubSpot, but that doesn't mean they need the same permissions as internal staff.

Consider three common situations:

• An event contractor needs to manage registrations and attendee communications, but has no reason to access deal values or service history.
• A marketing agency needs to create emails and landing pages, but shouldn't automatically have permission to export the database or modify unrelated workflows.
• A temporary administrator is covering someone on leave and needs additional access for a defined period, not indefinitely.

Access should reflect the work someone is responsible for, rather than how much you trust them.

When external access is granted, agree on when it should be reviewed or removed. Offboarding should be part of the process from the beginning, not something remembered months after the engagement ends.

HubSpot Permissions Should Evolve as the Organisation Changes

The permissions you configure at implementation won't necessarily remain appropriate as the business grows.

There are several situations that should trigger a review:

• New employees joining or existing employees leaving
• Changes to responsibilities within a team
• New regions, branches or business units
• Additional HubSpot hubs, subscription tiers or functionality
• New integrations and connected applications
• Migrations that introduce records and users from a legacy system

We recommend making access reviews part of regular HubSpot governance, alongside property management, workflow reviews and data maintenance.

It's a relatively manageable exercise when done consistently. Leave it for several years, and it becomes much harder to understand who has access to what, and why.

Poorly managed permissions can also contribute to declining data quality. The more people who can change information without clear responsibilities, the harder it becomes to maintain consistency.

What We Configure in a HubSpot Implementation

When we implement HubSpot, we design permissions alongside the data model and operational processes, rather than leaving them until the final stages of the project.

That includes:

• A role and access matrix based on how the organisation actually operates
• User seats and team structures, including main teams, extra teams and nested teams where available
• Role-based permissions and saved permission sets where supported
• Property-level restrictions for commercially sensitive information
• Documented administrative and Super Admin responsibilities
• Reporting and dashboard access for leadership and regional teams
• Access requirements for connected applications and extensions
• Governance processes for access reviews, new starters and departing staff
• Handover documentation so the structure can be maintained as teams change

HubSpot Permissions: Frequently Asked Questions

What are HubSpot permissions?

HubSpot permissions determine what users can view, create, edit, delete, export and administer within a HubSpot account. Permissions can be configured for individual users or through saved permission sets on Enterprise, with record access scoped according to ownership and team structures.

What is the difference between HubSpot teams and permissions?

Teams organise users into groups, while permissions determine what those users can access and do. The two work together through team-based record visibility. For example, a user with access to their team's records can work with records owned by the relevant team members, subject to their configured permissions and any applicable team hierarchy.

How many Super Admins should a HubSpot account have?

There's no fixed number. Super Admin access should be limited to people who genuinely need account-wide administrative control. Those responsibilities should be documented and reviewed whenever roles change.

Can you restrict access to individual HubSpot properties?

Yes, on Enterprise. HubSpot allows view and edit restrictions on individual properties for selected users and teams. Super Admins aren't subject to these restrictions, and properties may still be populated through the API or during manual record creation. Property restrictions should therefore complement the wider permissions structure.

Good HubSpot Permissions Should Disappear Into the Background

When HubSpot permissions are configured properly, most people shouldn't need to think about them.

They log in, find the information they need, update the records they're responsible for and get on with their work. They aren't constantly requesting access to do their jobs, and they aren't seeing information they have no reason to access.

That doesn't happen automatically. It comes from understanding how the organisation operates and configuring HubSpot to support it.

At Engaging Partners, we work with operations and revenue leaders to design HubSpot architecture, permissions and governance around the way their businesses actually run.

If your HubSpot permissions were configured during implementation and haven't been reviewed since, get in touch and let's look at whether they're still working for your organisation.