HubSpot Field-Level Permissions: Restricting a Property, and the Boundary the Restriction Stops At
HubSpot field level permissions explained: the four access levels, how far a restriction reaches, why the API bypasses it, and when to use something else.
Paul Maxwell
AUTHOR
GET WEEKLY REVOPS INSIGHTS
No spam. Unsubscribe anytime.
Every portal reaches a point where some field on a record should not be readable by everyone who needs to open that record. Deal margin, negotiated discount, contract terms, or a figure that feeds someone's compensation — and two failures follow, pulling in opposite directions. In the first, the value is restricted on the record and then appears in a dashboard the whole company opens on Monday, so the restriction was theatre. In the second, a restriction is treated as a security control, an auditor or a customer is told the data is protected, and the protection turns out to be an interface behaviour that any API token walks straight past.
This article explains what HubSpot's property restriction does, how far it reaches, and where it stops. It starts with the four access levels and who each one is for, then covers the propagation that makes the feature worth having — a restricted property stays restricted in saved views, workflows, reports and dashboards — and the properties the model refuses to restrict at all. It then draws the enforcement boundary, which is the fact everything else depends on, and follows it into what that means for integrations. After that: the configuration procedure, the business case, and the reported symptoms that map back to each mechanism.
A property restriction is per-property access control on Enterprise subscriptions, configured by a Super Admin — the permission level required to restrict a property, and the level that sees every property regardless of restriction. Sensitive data properties are a separate HubSpot feature for regulated data categories, with their own documentation and constraints; related to property restriction, and not the same thing.
The Four Access Levels
The restriction dialogue offers four settings, and the choice between them is a choice about who is being protected from what.
| Access level | Who can see and edit | The case it fits |
|---|---|---|
| Access levelPrivate to Super Admins | Who can see and editSuper Admins only | The case it fitsA field a small administrative group maintains and nobody else needs |
| Access levelEveryone can view and edit | Who can see and editAll users | The case it fitsAn unrestricted property, stated explicitly rather than by default |
| Access levelEveryone can view | Who can see and editAll users view, Super Admins edit | The case it fitsA value people must read and must not change, such as a calculated commercial term |
| Access levelAssign to users and teams | Who can see and editNamed users and teams, each set to view-and-edit, view-only, or no access | The case it fitsCommercial sensitivity, where one function owns the number and others legitimately read it |
The fourth is where most commercial-sensitivity designs land, and the working pattern is view-and-edit for the owning function, view-only where consumption is legitimate, and no access elsewhere — and it is worth writing down which is which before opening the dialogue, because the dialogue asks for the answer one team at a time.
The Reach of a Restriction
A restricted property changes the experience of everyone outside its access list, and the change reaches past the record page. On the record, the value is replaced by a restricted-access icon rather than shown, and a user without edit access who hovers the field is told they lack permission to change it.
The propagation is the part that makes the feature useful rather than decorative. Users without access cannot view records in saved views whose filters are built on the restricted property, and workflows, reports and dashboards reflect the same boundary. A margin figure hidden on the record but visible in a shared dashboard would not be hidden in any sense that matters, and this is the failure the propagation prevents.
Properties the Model Excludes
Some properties cannot have view access restricted, because a record whose identity is invisible is not a record anyone can work with. The exclusions cover contact first name, last name and email; company name and domain; deal name, pipeline and stage; ticket name and status; and pipeline properties on custom objects. Record ID edit access cannot be restricted on any object.
This is worth knowing before a design depends on it. A plan to hide which pipeline a deal sits in, or which company a contact belongs to, does not fail at configuration time with a clear error — it fails at design time, and the earlier it fails the cheaper it is.
The Enforcement Boundary
Everything above describes the interface, and the documentation states the limit on it plainly: all users, regardless of access, can set or edit restricted properties through HubSpot's API, or when manually creating a record. HubSpot recommends against using property restrictions as a security measure for that reason.
Read that as a division of labour rather than as a defect, because inside the boundary the feature does exactly what it claims: it keeps a sensitive figure out of casual view, prevents accidental edits, and reduces the surface for commercial terms leaking through ordinary internal traffic. Outside it, the feature is not weak — it is absent, and no configuration moves the line.
The design rule follows directly: property restriction is appropriate wherever the requirement is governance — reducing exposure, avoiding accidents, keeping commercial figures away from people with no reason to see them. Where the requirement is regulatory or contractual — where somebody will be told the data is protected — the answer is the sensitive-data feature set, private-app scope hygiene, and in the strongest cases not putting the data in the CRM at all. Absence remains the only field-level control that cannot be bypassed.
Integrations on the Unenforced Side
Connected apps write through the API, which means restrictions do not bind them. An integration can populate, overwrite or clear a restricted property on every record it touches, and it will do so quietly and at whatever volume it runs.
Whether that is a defect or the intended design depends on the integration, since a finance writeback should be updating a restricted margin property — that is its job, and the restriction exists to keep humans out of it, not the system of record. What matters is that this be decided when the restriction is created, and written down, rather than discovered later when a number changes and no user appears in the property history. That review is also the point at which to check which private apps hold write scopes on the object at all, since a scope granted for one purpose stays granted for every other.
Configuration Procedure
- Confirm the portal is on an Enterprise tier and your account holds Super Admin permissions. Both are hard requirements and neither has a workaround.
- Check the property is not one of the exclusions above before designing anything around restricting it.
- Navigate to Settings → Data Management → Properties, select the object, hover the property, and choose More → Manage access.
- Set the access level, following the pattern decided in advance rather than deciding team by team inside the dialogue.
- Review every dashboard and report the property feeds from the account of a user outside the access list, and confirm the value is absent rather than merely de-emphasised.
- Verify both boundaries: as a restricted user, attempt to change the value on a record and confirm the refusal; as a Super Admin, confirm the property is still fully visible and editable.
- Record the restriction, its reason and its owner somewhere the next administrator will look. A property invisible to most users is also invisible to most future debugging, and an undocumented restriction is eventually diagnosed as a bug.
The Business Case for Property Restriction
What it buys is the removal of a category of accident. Most commercial data does not leak through attack; it leaks through a shared dashboard, an exported list, a screen in a meeting with the wrong people in the room. A restriction closes the ordinary paths, which are the paths the exposure actually travels on, and it does so without the friction of moving the data somewhere else or maintaining a parallel system for the sensitive fields.
What it costs is Enterprise tiering, Super Admin time, and a permanent debugging tax: every future "the property is missing" question has an extra candidate cause, and whoever inherits the portal will not know the restriction exists unless somebody wrote it down. There is a subtler cost in expectation management, since a control that looks like security invites people to describe it as security, and the first time that description is repeated to a customer or an auditor it becomes a claim the portal cannot support.
The case is strongest for commercial sensitivity inside a trusted team — margins, discounts, negotiated terms among colleagues who are not adversaries but do not all need the number. It is weakest wherever the threat model includes someone with API access and a reason to look, which is to say wherever it is genuinely a security question rather than a governance one.
Reported Problems and Their Causes
A restricted value reaches the wrong audience anyway. Someone with access built a report or export and shared the artefact onward, and restrictions govern the platform rather than files and screenshots. Exports of restricted data need to be treated as their own controlled channel, with the same list of people attached.
A user reports that a property has vanished from a record. They were removed from, or never added to, the property's access list, and the restricted icon reads as absence at a glance. On an Enterprise portal, check Manage access before checking anything else.
A restricted property changes value with no editor in its history. An integration or API call wrote it, which restrictions do not prevent. Audit which connected and private apps hold write scopes on the object, and read the property history for the acting app rather than for a user.
An administrator cannot restrict a property at all. The account lacks Super Admin, the portal is below Enterprise, or the property is one of the excluded essentials. All three take under a minute to check, and the answer is one of them.
Boundaries of This Article
This covers property-level restriction on CRM objects. The adjacent systems that complete a real access design — team-based record access, permission sets, and the sensitive-data feature set — each have their own documentation and tier gates and are not treated here. What the feature relies on in practice is shown in a margin-visibility restriction inside an integration engagement.
Behaviour, tiers and the exclusion list are as documented in August 2026, and HubSpot's permissions guide is authoritative as the platform changes. The API bypass in particular is documented current behaviour rather than a bug awaiting a fix, so a design should not be built on the assumption that it will be closed.
In Summary
HubSpot's property restriction is an Enterprise feature configured by a Super Admin, offering four access levels: private to Super Admins, everyone view and edit, everyone view with Super Admin edit, or assignment to named users and teams. Restrictions propagate — a user without access cannot reach the value through a saved view, a report, a dashboard or a workflow — and some identity-bearing properties, including names, email, domain, pipeline and stage, cannot have view access restricted at all.
The boundary is the thing to design around: restrictions are enforced in the interface rather than in the data layer, so API calls, private apps, connected integrations and manual record creation all set restricted properties freely. That makes the feature a governance control and not a security control, and HubSpot says so in its own documentation.
Use it accordingly, and write down what you did. Restrict the property, review the dashboards it feeds from an account that cannot see it, decide deliberately which integrations should be allowed to write it, and leave a note naming the restriction's owner and reason. The note is the part everyone skips, and it is the reason a future administrator spends an afternoon debugging a missing field that is working exactly as designed.