HubSpot data governance plans routinely assume that restricting access is a setting anyone can apply to anyone: pick a pipeline, pick a team, limit who can see it. Any real HubSpot data governance super admin review has to start from the opposite assumption, because that plan breaks down completely at the Super Admin layer. HubSpot’s own documentation states plainly that Super Admins can view, edit, delete, and merge all CRM records, and that Super Admin permissions must be removed before record-level restriction can even be configured for that person. A governance plan that assumes a restriction applies while someone still holds Super Admin has not actually restricted anything for them.
HubSpot Data Governance Super Admin Override
Per HubSpot’s own documentation on assigning access to records, the language used is unconditional, not situational: “Super Admins can view, edit, delete, and merge all CRM records.” The very next sentence removes any ambiguity about whether this can be worked around while keeping the role: “Super Admin permissions must be removed before you can restrict access to CRM records.” That is not a description of what a Super Admin is capable of doing if they chose to; it is a statement that the record-level restriction setting itself does not apply to that account while Super Admin is active.
This matters for governance specifically because a plan built around “restrict the sensitive pipeline to these three reps” is only true for people who do not hold Super Admin. Anyone who does hold it, whether that is a long-serving admin, a RevOps lead, or a legacy holdover nobody has audited in a year, can see, edit, delete, and merge every record on that pipeline regardless of what the restriction says, and the restriction setting offers no way to change that for them specifically. The practical consequence for a governance audit is that the actual scope of any restriction is not what the settings screen shows; it is what the settings screen shows, minus everyone who currently holds Super Admin, a group that has to be checked separately and does not appear anywhere on the restriction’s own configuration page.
What Super Admin Actually Overrides
HubSpot’s own user permissions guide extends the same override to a second, separate category: restricted assets. Its own wording: “Even if access to specific assets has been restricted to certain teams or users, Super Admins still have the ability to view them.” The assets named are templates, sequences, documents, and playbooks. So the override is not limited to CRM records; it spans two structurally different permission systems, record-level access and asset-level access, both of which treat Super Admin the same way.
The same guide documents several further Super Admin-specific behaviours worth knowing for a governance audit: “Super Admin permission sets aren’t modifiable,” meaning the role itself cannot be scoped down the way a custom permission set can. “Only a Super Admin can set another user as a super admin,” which means Super Admin propagation is entirely self-contained within the group that already holds it. “Only a Super Admin can access the Communications index page.” And the existence of a specific “Data quality tools access” toggle for non-Super Admin users implies Super Admins already have that access without needing it granted.
A third permission surface follows the same pattern. HubSpot’s own documentation on restricting property access states plainly: “Super Admin permissions are required to restrict a property or view all properties regardless of the applied restriction.” That same page carries an honest caveat worth including in any governance plan built around it: “this feature doesn’t provide complete restricted access, so it’s not recommended to use property restrictions as a security measure,” since “all users, regardless of access, can set or edit restricted properties via HubSpot’s API, or when manually creating a record.” Property restriction is a workflow-friction control, not a genuine access barrier, on top of the Super Admin override that already applies to it.
Restriction Type vs Whether It Applies to Super Admin
| Restriction type | Applies to a Super Admin? |
|---|---|
| Record-level view/edit/delete restriction on a CRM object | No: not configurable for a Super Admin until the role is removed |
| Restricted asset visibility (templates, sequences, documents, playbooks) | No: Super Admins retain view access regardless |
| Property view/edit restriction on a specific field | No: Super Admin permissions are required to view all properties regardless of a property’s restriction |
| Being set as a Super Admin in the first place | Only another Super Admin can do this |
Reading the table the other direction is the useful governance exercise: every restriction type HubSpot documents as bypassable by Super Admin is a restriction that only means something once the list of Super Admins on the account has been deliberately reviewed, not assumed. The property row is worth a second look for a different reason too: even for a non-Super-Admin user genuinely blocked from a restricted property in the interface, HubSpot’s own documentation is explicit that the block is a UI-layer control rather than a hard data barrier, since HubSpot states plainly that all users, regardless of the property restriction, can still set or edit the same property via the API or when a record is created manually.
Where Teams Get This Wrong
Every restriction covered above shares the same structural cause: HubSpot’s permission model has one role that sits above the restriction system entirely, and the interface for configuring any given restriction does not surface that fact at the point someone sets it up. A governance review that only checks the restriction settings themselves, without separately pulling the full list of Super Admins and asking whether each one genuinely needs that level of access, is checking the wrong layer.
None of these gaps show up as an error. A restriction saved successfully in the settings screen looks identical whether or not it actually constrains every account holder, because HubSpot’s interface does not warn that Super Admins are exempt at the point the restriction is configured, and nothing prompts anyone to cross-reference the restriction against the current Super Admin list before treating it as done.
The first common mistake is treating Super Admin as simply “the highest permission level” rather than as a role that structurally sits outside the record- and asset-level restriction system entirely, which changes how a governance audit needs to be scoped.
The second common mistake is not periodically auditing who actually holds Super Admin, since the role tends to accumulate over time, whoever set up the account, whoever needed the higher access temporarily and was never downgraded, without anyone treating that list as sensitive in its own right. A Super Admin list that has never been reviewed is, functionally, the actual access-control boundary for every record and asset restriction on the account, whether or not anyone has framed it that way.
The third common mistake is assuming a Super Admin’s access can be selectively narrowed by adjusting the same record-level and property-level settings used for everyone else, when HubSpot’s own documentation is explicit that record restriction is not configurable for a Super Admin at all until the role itself is removed. There is no partial-Super-Admin state to fall back on in the meantime; the choice is between full Super Admin access and removing the role entirely, then rebuilding a narrower permission set from scratch.
The fourth common mistake is assuming asset restrictions, such as a template or playbook limited to a specific team, are private from everyone outside that team, when HubSpot’s documentation states Super Admins retain view access to restricted assets regardless of team assignment.
The fifth common mistake is treating a property restriction as a genuine security control on its own, when HubSpot’s own documentation explicitly warns it is not recommended as one: the interface block does not extend to the API or to manual record creation, so a property restriction alone does not stop the data from being set or read through those other paths, with or without Super Admin involved at all.
Related Reading
For the CRM foundation this governance work protects, see HubSpot Consultancy. For the RevOps side of keeping account access trustworthy, see RevOps Consultancy. For a related data-quality build, see HubSpot CRM Data Management: Clean Data, Automation and Lead Scoring.
Go deeper: HubSpot Lifecycle Management: Contacts vs Custom Objects · HubSpot Lead Routing Automation · n8n Consultancy
Frequently Asked Questions
Can a HubSpot record-level restriction be applied to a Super Admin?
No. HubSpot’s own documentation states plainly that Super Admin permissions must be removed before access to CRM records can be restricted for that user. Record-level view, edit, and delete restrictions are simply not configurable for an account while it holds Super Admin.
Can Super Admins see assets that are restricted to specific teams?
Yes. HubSpot’s own documentation states that even when access to specific assets, such as templates, sequences, documents, or playbooks, has been restricted to certain teams or users, Super Admins still have the ability to view them regardless of that restriction.
Who is allowed to make another user a Super Admin in HubSpot?
Only an existing Super Admin. HubSpot’s own documentation states this directly, which means Super Admin status can only ever propagate from within the group that already holds it, not be granted by a lower-permission admin role, however much other access that role otherwise carries.
Can a Super Admin’s own permission set be scoped down like a custom one?
No. HubSpot’s own documentation states that Super Admin permission sets aren’t modifiable, unlike custom permission sets built for other roles. The only way to reduce a Super Admin’s access is to remove the Super Admin role from that user entirely.