What should a HubSpot governance checklist cover?
A HubSpot governance checklist covers seven areas: access and permissions, the data model and properties, data quality and validation, naming conventions, automation, integrations, and reporting. Each item has an owner and a review rhythm, so the portal stays understandable and safe as more people and processes depend on it.
Use this checklist before a new build, after a migration, or in a quarterly portal review. All 47 points are listed below, free and without a form, and in a spreadsheet you can score.
Get the template: the HubSpot Governance Checklist, a fillable PDF workbook. Enter your name and email and the download starts straight away.
We'll also send occasional HubSpot tips by email. Unsubscribe anytime. See our privacy policy.
Thanks, your download should start now. Download the fillable PDF or the spreadsheet (XLSX).
The spreadsheet adds a score dropdown for every point, a summary that counts done items per section, the owners, review rhythm and naming tables below, and a change log.
Access and permissions (8)
- Super admins limited to the people who own the portal
- Permissions defined per role (permission sets on Enterprise, templates on Professional)
- Teams match the real reporting structure
- Export rights limited by role
- Bulk delete rights limited by role
- Departed users deactivated within a day
- Records of departed users reassigned
- Access tested with a normal user account, not an admin
Data model and properties (10)
- Every custom property is in the property catalog
- Each property has an owner and a one-line definition
- No duplicate properties for the same concept
- Unused properties archived
- Dropdowns used instead of free text where values repeat
- Required properties set on forms and imports
- Associations between objects documented
- Record ID of source systems stored for imported data
- Sensitive properties restricted to the roles that need them
- Lifecycle stage and lead status definitions written down
Data quality and validation (6)
- Email, phone and country formats standardized
- Company domains normalized
- Duplicate review runs every week
- Imports require a matching key
- Only trained users can import
- Data quality exceptions have a named owner
Naming conventions (6)
- Naming convention published for properties
- Naming convention published for workflows
- Naming convention published for lists and views
- Naming convention published for reports and dashboards
- Test and temporary assets clearly labeled
- Old assets archived, not left active
Automation (7)
- Every workflow has a named owner
- Every workflow has a one-line purpose
- No two workflows set the same property in conflict
- Workflow errors reviewed each week
- Changes to live workflows tested on sample records first
- Sequences and automated emails reviewed each quarter
- A change log records what changed, when and why
Integrations (5)
- Every connected app listed with its owner
- Field ownership defined for each shared field
- Sync errors alert a named person
- Integrations update on a stable external ID
- Unused apps disconnected
Reporting and review (5)
- Dashboards leadership relies on are listed
- Each key report has an owner who checks it
- Report definitions match lifecycle and pipeline definitions
- Unused dashboards archived
- Full governance review held every quarter
How should you use this checklist?
Assign each section to a named owner, mark every item as done, partly done or not done, and fix the not-done items in priority order: access first, then data, then automation. Re-run it every quarter and keep the results, so you can see whether the portal is getting healthier or drifting.
| Score | Meaning | What to do |
|---|---|---|
| Done | In place, owned and checked on schedule | Keep the review rhythm |
| Partly done | Exists, but not complete, written down or owned | Finish it within the quarter |
| Not done | Missing | Fix in order: access, data, automation, then the rest |
Count the "done" items per section. A section with most items not done is where the next problem will come from, so fix it before adding anything new to the portal. If you have never checked the portal as a whole, start with our HubSpot audit checklist and come back to this list afterwards.
No internal CRM owner? Ongoing HubSpot administration keeps governance running.
Who owns each part of HubSpot governance?
One portal owner is accountable for the whole checklist, and named owners look after each area: properties, workflows, integrations and reports. Owners don't have to do every change themselves. They approve changes in their area, know why each asset exists, and are the person others ask before editing it.
| Role | Owns | Typical person |
|---|---|---|
| Portal owner | Access, the checklist, the quarterly review | RevOps or operations lead, or your HubSpot admin |
| Property owners | Definitions and allowed values for their properties | The team that uses the field most, such as sales ops for deal fields |
| Workflow owners | Purpose, testing and errors for their workflows | Whoever requested or built the workflow |
| Integration owners | Field ownership and sync errors for each connected app | The admin, or the team that uses the app |
| Report owners | Accuracy of the dashboards leadership uses | The manager who presents the numbers |
Write the owners next to each item in your copy of the checklist. When someone leaves, reassigning their governance items is part of offboarding, together with deactivating the user and reassigning their records.
How often should each part be reviewed?
Weekly for the things that break quietly: duplicates, workflow errors and integration sync errors. Monthly for users, permissions and assets nobody uses. Quarterly for the full 47 points, plus after every migration, new integration or major rebuild. A short weekly check prevents most of the clean-up a quarterly review would otherwise find.
| When | What to check | Checklist items |
|---|---|---|
| Weekly | Duplicates, workflow errors, sync errors, data quality exceptions | 21, 24, 34, 40 |
| Monthly | New and departed users, permissions, unused properties, lists and dashboards | 1–8, 12, 30, 46 |
| Quarterly | All 47 points, scored and compared with the last review | 1–47 |
| After a change | Migration, new integration, new team or major rebuild | The affected sections |
What does a good HubSpot naming convention look like?
A good convention tells you what an asset does and who it belongs to from its name alone. Start workflow, list and report names with the team, then the object, then the purpose. Give properties plain labels and stable internal names. Mark test and temporary assets so they're easy to find and archive.
| Asset | Pattern | Example |
|---|---|---|
| Workflow | Team · Object · What it does | Sales · Deal · Create onboarding ticket at Closed won |
| List or segment | Team · Object · Who is in it | Marketing · Contact · Webinar attendees not yet MQL |
| Report | Team · Metric · Breakdown | Sales · Pipeline created · By source and month |
| Property | Plain label; internal name that won't need changing | "Primary use case" with internal name primary_use_case |
| Test asset | Prefix TEST and a date | TEST 2026-10 · Lead routing v2 |
The exact pattern matters less than using one pattern everywhere. Publish it next to the checklist, and fix names as you touch assets rather than renaming everything at once.
What should a HubSpot change log record?
Every change to live properties, workflows, permissions, integrations or reports, with the date, who made it, what changed, why, and how it was tested. A shared sheet is enough. When a number in a report suddenly moves, the change log is usually the fastest way to find out why.
- Date and person: when the change went live and who made it.
- Asset: the workflow, property, permission set, app or report that changed.
- Change and reason: what was changed, and the request or problem behind it.
- Test: how it was checked, for example on sample records first.
- Rollback: how to undo it if something breaks.
HubSpot also keeps its own history, such as property history on records. The change log adds the part HubSpot can't know: why the change was made.
Key takeaway: Governance is not a pile of restrictions. It is the shared system that keeps a portal usable, explainable and safe as it grows.
Frequently asked questions
What is HubSpot governance?
HubSpot governance is the set of rules that keeps a portal understandable and safe as it grows: who can access and change what, how properties and assets are named and owned, how data is validated, and how automation, integrations and reports are reviewed.
How often should you review HubSpot governance?
Run the full checklist every quarter, after a migration, and before any major rebuild. Weekly, check the fast-moving items: duplicates, workflow errors and sync errors.
Who should own HubSpot governance?
One named portal owner, usually in operations or RevOps, with property and workflow owners named for each area. If nobody owns the portal, governance decays within months; that is the gap ongoing HubSpot administration fills.
Sources
HubSpot documentation behind the feature and tier notes above, checked October 2026. HubSpot changes features and tiers often, so check your own portal too.