Managing HubSpot Edits / Permissions For a Team - What's the Best Practice?

[AZistler]

Hello, and thank you for your time!

Our team is pretty new to HubSpot, and currently, nearly everyone is a SuperAdmin. Three departments consisting of ~3 users are working within HubSpot creating their own properties, workflows, forms, etc.

I'm building out several SOPs and guidelines for HubSpot usage, and I'm running into one particular sticking point regarding how edits should be made. We're beginning to run into the issue of users utilizing various properties, workflows, etc that are no longer updated. Or, they get updated by their creator and end up breaking some other function.

My current idea: Keep an additional spreadsheet of all properties, workflows, etc, how they're used, and which individual user is using them. If someone wants to edit a structure, they check the sheet and then check in with the listed users. Users are required to add their structure to the sheet when it is created or mark themselves as a user if they didn't create the structure.

There is another idea, whereby the user interested in editing a property would contact the designated HubSpot Lead for their department and request a change. But, I worry this process may exclude some users.

---

I understand people often use the roles and permissions functionality in HubSpot to combat this with larger teams, but our team is pretty small and tends to stick to their own department's section... I'm hesitant to simply remove editing capabilities for users. But, our properties and workflows are becoming more and more interdependant.

I would love any and all advice and input on how you would handle these distributed edits within the various parts of the database.

— Is this issue common or are we crazy for allowing such wide editing permissions?

— Should we simply restrict editing permissions for all but a few people - or create an SOP similar to the above for checking in with other users before editing? 

Thank you very much again in advance!

[karstenkoehler · Accepted solution]

Hi @AZistler,

Having taken over a lot of chaotic portals, I'd recommend limiting property creation to a select few people. Users maintaining different postal code fields alone can be a big headache. Duplicate properties or properties that are set up incorrectly can cause a lot of data quality problems further down the line. Especially if you're on a Professional subscription and automation relies on data quality and properties.

---

@AZistler wrote:

My current idea: Keep an additional spreadsheet of all properties, workflows, etc, how they're used, and which individual user is using them. If someone wants to edit a structure, they check the sheet and then check in with the listed users. Users are required to add their structure to the sheet when it is created or mark themselves as a user if they didn't create the structure.

---

This information would be available in the property settings already: Each property in HubSpot comes with a description field, the information who created it. So the question arises: If you can't get users to maintain it here, would they do so in a spreadsheet? A spreadsheet could be useful if you want to include more information that can be stored in the property settings.

I'd recommend granting system-critical editing permissions (properties, workflows) only to a small number of users. These users should be on the same page about SOPs, how properties are created and maintained and receive training on a regular basis. This might seem like overdoing it, but it'll always be less work than cleaning up a mess or data quality problems at a later stage.

For all other assets (workflows, forms), keeping a spreadsheet could be useful, too. In general, a consistent naming convention will also do wonders.

Best regards!