Sales Operations System
Individual fields can be restricted, so some users can see or edit a field and others cannot.
Cost price, margin, commission and personal data all sit on records that many people legitimately need to open. Without field-level control the only lever is hiding the whole record.
Yes where an arbitrary field can be restricted to a subset of users, whether for reading or for editing.
Partial where only specific named fields can be hidden - typically cost or margin - with no general mechanism.
No where permissions stop at the object, the feature or the record, and every user who can open a record sees all of its fields.
Controlling who may create, rename or delete a field is a structural permission, not a field-level one, and does not count.
The vendor's security and privacy paper lists field-level security, controlling what individual users can see, as a configurable control, and the customisation training includes securing a field.
The documented permission model grants a user group access to whole features - lists, campaigns, forms, templates, deals, accounts, contacts, automations, reports, saved responses and landing pages - plus usage limits. No mechanism for hiding or locking an individual field from a subset of users appears in vendor documentation.
Individual custom fields can be secured so that only users granted the privilege can see them, with view and edit access granted separately and new privileges created as needed; a user without the privilege does not see the field at all. The constraint is scope: the documented mechanism applies to custom attributes, and no vendor document describes restricting a standard field in the same way.
The documented permission surfaces are objects, lists, dashboards, workflows and sequences. Records and object attribute values are treated as one unit - visible and editable by everyone by default, with read only as the available restriction - and no vendor page describes limiting an individual attribute to a subset of members.
Profiles control access at module and feature level only. The documented categories are pipeline permissions, basic permissions over contacts, companies, pipelines, notes, files, activities and dashboards, advanced features such as workflows, forms, user management, bulk actions and data administration, and channels. No mechanism for hiding an individual field or making it read only for a subset of users appears in vendor documentation.
The documented role model grants or withholds whole capabilities such as inviting members, viewing billing, seeing connected accounts and deleting the workspace. No vendor documentation describes restricting an individual attribute to a subset of users, and the attributes guide contains no visibility or permission property on a field.
Access is granted by role - restricted user, standard user, administrator and super administrator - with an additional per-user right to export data. Vendor documentation describes no mechanism for hiding or making read-only an individual field for a subset of users.
An individual custom field can be restricted so that only nominated roles may edit it, set from the field's configuration. The documented control is over editing rights on custom fields; vendor documentation does not describe hiding a field from a role, nor applying the same control to built-in fields, so the capability is present but narrower than full field-level permissioning.
Individual fields on leads, people, companies, opportunities, tasks and projects can be set read-only, on creation, on editing, or both. The control is coarse: it applies to all non-administrator users rather than to a chosen user or team, administrators can always edit, the API and import bypass it, and fields central to the workflow such as the opportunity stage cannot be made read-only. No mechanism for hiding a field from a subset of users is documented.
Group permissions distinguish between editing record values and editing the group structure, so a member who can edit may change values but cannot alter the fields themselves. That is a structural control, not a per-field one. No vendor documentation describes restricting an individual field to a subset of users.
Each field can be set per role to Editable, Read-only or Hidden. Required fields cannot be hidden, and hiding a controlling field also hides its dependent fields regardless of the role setting.
Individual properties can be set to private to super admins, view only for everyone, or assigned to named users and teams for view or edit. Users without view access see a restricted access icon in place of the value. HubSpot cautions that property restrictions are not a complete access control and that restricted properties can still be changed through the API or at record creation.
With Advanced Permissions enabled, an administrator can set any field on any standard or custom object to Read Only or Hidden for a given profile, and the setting carries through to record layouts, list views and reports.
The roles and permissions documentation describes feature-level permissions and record visibility by assignment, and makes no reference to restricting the visibility or editability of an individual field.
Column-level security is enabled per column and governed by column security profiles assigned to users or teams, each setting Read, Update, Create and Read unmasked to allowed or not allowed, with optional masking rules. Constraints are documented: lookup, formula, virtual, primary name and several system columns cannot be secured, and system administrators are never denied the data.
Column permissions let a board owner restrict who can edit a column or who can view it, and access is granted to named users or a whole team. A single column cannot carry view and edit restrictions at the same time, the Tags column does not support view restriction, and board owners always see and edit everything.
The permissions an administrator can assign to a user or group are feature and object level - bulk export, bulk delete, contact privacy, API access, configuring pipelines, deal privacy, viewing and editing private deals, managing activity settings, managing custom fields, managing groups and billing. No permission restricts visibility or editing of an individual field.
Access is controlled by role-based permissions that govern what a user can do, and by team-based restrictions that govern which records a user can see. Vendor documentation describes no mechanism for hiding an individual field from a user or making it read-only for one role.
Permission sets govern what users can do and operate across apps, global permissions and record creation or editing rights. Vendor documentation describes no mechanism for restricting an individual field to a subset of users; access is granted at the object and feature level.
A Restricted Dictionary can be applied to selected users to remove Cost Price and Margin from their view on product records and quotes. The vendor states plainly that it hides only those two fields and does not prevent those users editing prices on quote lines. No general mechanism for restricting an arbitrary field to a subset of users is documented.
Field permissions set Read and Edit, Read Only or No Access on each individual field, assigned through profiles or permission sets, and the restriction carries through to detail pages, reports, list views and the API.
Pipeline roles govern whether a user can add, rename, delete or reformat columns, which is control over the structure rather than over who may read or write a particular field's values. A custom permission option grants view or edit access to individual features on a per-pipeline basis, again at feature level. No mechanism for restricting an individual column to a subset of users is documented.
Field visibility and editing rights are set per profile, so an administrator can hide a sensitive field from some users or make it read-only for them. A separate masking capability, installed as an add-on, obscures the contents of nominated fields and is configured by role, by profile and by module.
Each field's permission can be set per profile from the fields list page, with three states - read and write, read only, or do not show, which blocks both viewing and editing. The vendor positions this as the way to keep sensitive values away from users who still need the rest of the record.