Hey there everyone!
We have 30+ users across multiple departments, and historically permissions have been way too open. I tried applying a “standard” permission set across the board (from the default provided), but that quickly led to complaints when users lost access they relied on. That experience is what kicked off this RBAC project.
My plan was to create a spreadsheet to bring to each department manager. The idea is that managers can review the available permission options, select what they think their team members need, and then I’ll meet with them for 15–20 minutes to answer questions and finalize their decisions.
The challenge is that permission options are really granular, and explaining them gets complex. I’ve been referencing the HubSpot User Permissions Guide. But when I try to turn that into a usable spreadsheet, it becomes a nightmare. I’m stuck between:
- Creating dropdowns for managers to pick valid options (e.g., All/Team/Own/None), — see the sample image of the spreadsheets I began drafting at the end.
- Leaving blanks for the different object/permission type and just asking them to reference the permissions guide to fill it in
I’m worried that the spreadsheet I’m making is too overwhelming, but I also don’t want it to be so vague that I spend all my meetings just explaining what each permission means.
Has anyone else built a permissions matrix or a similar tool for managers to review? How did you structure it so it was simple enough for non-technical managers but still accurate for HubSpot’s complexity?
Any templates, approaches, or lessons learned would be hugely appreciated!
V1
V2
Hi @RxRedefined
Thank you for reaching out to the Community!
I’d like to invite some community members who are subject matter experts to join this conversation.
@karstenkoehler @ChristinaKay @MichaelMa - Would you be able to share any insights on this? Your expertise would be greatly appreciated.
Best,
Victor
Hi @RxRedefined,
I have approached permissions with spreadsheets in the past, multiple times, but over time given up on this approach, for a few reasons:
- The complexity you’re running into
- HubSpot changing permission options often, requiring constant updates on this sheet
- The discrepancy between which permissions somone thinks a user should have versus what they actually should have
This is not to say that it’s a bad idea to create such a sheet, only that it can be a lot of work. Instead, I typically now work with ticketing systems that use guiding questions to understand which general role a user is going to have. They then need to complete learning materials according to that role and get one of number of permission sets (e.g. marketing admin, marketing contributor, marketing viewer, sales account executives, sales development representative, etc).
If you want to go the route of a sheet, I would probably operationalize everything into simple language yes/no questions which are then feeding, via formulas, into what is now your v2.
For example, in sheet 1, someone would answer the questions “Should the user be able to delete all contacts” with “Yes” and that would set the contact delete permissions in your v2 to “All”. ChatGPT could probably help with turning the permissions into a long list of simple language questions.
As a HubSpot admin, I would however not exactly be excited about super detailed requirements for new users, and the next nuance of permissions which potentially require a new permission set. Each permission set needs to be maintained, reviewed occasionally etc – so I think there’s a lot of value in simplification and grouping.
Best regards!
Hi @RxRedefined , this pain is very real. Almost every HubSpot portal that grows past 20-30 users hits this exact wall.
You’re already seeing the core issue: HubSpot permissions are both granular and evolving, which makes a “complete” spreadsheet brittle. In practice, the spreadsheet usually fails not because of structure, but because managers are being asked to reason at the permission-flag level instead of at the job-to-outcome level.
What I’ve seen work best is a two-layer model, not a single exhaustive matrix.
Layer one is role intent, written in human language: what this person should be able to do, what they should never be able to do, and what data they should mostly work with. This can be a short form managers actually complete. Layer two is your internal admin sheet that translates those answers into HubSpot permission sets. Managers never touch the raw permissions.
Trying to expose “All / Team / Own / None” across every object almost always overwhelms non-technical leaders. Instead, collapse permissions into a few irreversible questions like “Can this role delete records?” or “Should this role see other teams’ pipelines?” Those answers map cleanly to multiple HubSpot toggles behind the scenes. Karsten’s suggestion of yes/no questions feeding formulas is exactly the right direction.
Also, resist the urge to create too many permission sets. In HubSpot, permission sets are an operational asset that need maintenance as features change. Fewer, well-named sets aligned to stable job functions age much better than hyper-customized ones. HubSpot’s own guidance leans this way, even if it’s implicit rather than explicit (HubSpot user permissions guide )
One last tip: document the why of each permission set, not just the settings. Six months later, that context matters more than the spreadsheet itself. Hope this helps, and you’re definitely asking the right questions here.
