Reporting and Dashboards | Entry 82
HubSpot reporting access control lets nonprofits separate viewing, editing, creating, owning, administering, sharing, and exporting. When combined with object, record, property, tool, seat, and account controls, it can give each user the information needed for their role without exposing sensitive constituent or organizational data unnecessarily.
A volunteer coordinator may need volunteer participation but not major-donor revenue. A box-office employee may need registration data but not grant projections. Marketing may need campaign results without sensitive constituent records. A board member may need summarized outcomes without individual donor details.
The goal is not restriction for its own sake. It is least-privilege access that still allows every person to do the work confidently.
This entry focuses on reporting tools, individual reports, dashboards, underlying data, and sharing or exporting. Broader CRM permissions matter where they affect reporting.
Hiding a report or restricting one property is not a complete security strategy. Effective protection requires coordinated permissions, governance, account security, integration controls, and documented policies.
Development, finance, marketing, programs, membership, volunteers, leadership, and boards may all need different views of performance. Unrestricted portal access is not required for collaboration.
| Access layer | What it controls |
|---|---|
| Reporting-tool permission | Access to reports, dashboards, and analytics tools |
| Report access | Who can view or edit an individual report |
| Dashboard access | Who can view or edit a dashboard |
| CRM object permission | Which record types a user can access |
| Record-level permission | Access to all, team-owned, or personally owned records |
| Property access | Who can view or edit specific fields |
| Tool-specific permission | Access to forms, campaigns, payments, and other sources |
| Export and sharing controls | Whether information can be downloaded or distributed |
| Subscription and seat | Which reporting and access features are available |
HubSpot currently documents several levels within reporting permissions:
When reporting access is disabled, the user will not see Reports in HubSpot's navigation. Administrative reporting access can override settings within the Reports permission area, so it should be assigned deliberately.
| User type | View | Edit | Create/own | Admin |
|---|---|---|---|---|
| Executive Director | Yes | Optional | Optional | No |
| Development Director | Yes | Yes | Yes | No |
| Development Officer | Yes | Limited | Optional | No |
| Volunteer Coordinator | Yes | Limited | Optional | No |
| Board Member | Approved delivery | No | No | No |
| CRM Administrator | Yes | Yes | Yes | As required |
| Temporary Volunteer | Only if necessary | No | No | No |
The final structure should reflect role responsibilities, training, data sensitivity, and reporting governance.
HubSpot reports can be private to the owner, available to everyone with view-only access, available to everyone with view-and-edit access, available to selected users, or available to selected users and teams when eligible Enterprise functionality is available.
These settings apply to reports not governed through a dashboard's access.
Dashboards can be private to the owner, available to everyone as view-only, available to everyone with view-and-edit access, or limited to selected users and teams on eligible subscriptions.
Super Admins and users with elevated reporting permissions may have broader access regardless of ordinary ownership or visibility. A dashboard labeled private should not automatically be treated as invisible to every administrator.
Reports may depend on contacts, companies, deals, payments, subscriptions, events, forms, campaigns, tickets, custom objects, or restricted properties. Some reports also require permission to the source tool, such as forms or CTA data.
Giving someone access to a dashboard does not eliminate the need to configure its related objects, records, properties, and tools correctly.
Record access for contacts, companies, deals, tickets, and other supported objects can be limited to all records, team-owned records, personally owned records, or no access where supported.
A regional development officer might see only donor records owned by that officer or team. Test the effect on shared donors, households, national campaigns, unassigned records, cross-object reports, executive dashboards, and team hierarchies before relying on this structure.
Eligible users can restrict property viewing and editing to selected users or teams. Reports using a restricted property may fail to load for users without access.
HubSpot notes that restricted properties may still be set or edited through certain API or record-creation paths. When stronger protection is required, restrict the relevant objects and tools as well. Property access should complement broader controls rather than replace them.
| Access level | Appropriate when |
|---|---|
| View only | The user monitors approved reports and should not change filters, formulas, or structure. |
| Edit | The user maintains the report, understands its definitions, and is responsible for updates. |
| Create/own | The user has reporting responsibilities, understands data architecture, and follows a review process. |
| Admin | The user genuinely needs broad reporting administration and oversight. |
A person who needs to see a report does not automatically need permission to change or create one.
| Role | Appropriate reporting access |
|---|---|
| Executive Director | Executive dashboards and approved strategic reports |
| Development Director | View, create, and edit fundraising reports |
| Development Officer | Fundraising reports and limited operational tables |
| Finance Staff | Revenue and payment reporting without unnecessary marketing access |
| Marketing Staff | Campaign reporting without broad access to sensitive financial properties |
| Volunteer Coordinator | Volunteer recruitment and participation reports |
| Box-Office Staff | Event and registration reporting required for operations |
| Program Manager | Program delivery and outcome reports |
| Board Member | Approved summarized reports or dashboard exports |
| CRM Administrator | Reporting architecture, permissions, and governance |
| Temporary Volunteer | Only what the defined task and timeframe require |
Board members may not need accounts in the operational CRM. Options include one-time dashboard emails, approved report images, PDF or presentation summaries, view-only access to a carefully designed dashboard, meeting presentations, or a separate board-management platform.
Remove individual donor, volunteer, participant, and employee detail unless there is a clear, approved need.
Interns, volunteers, contractors, seasonal staff, and event workers may require access only for a limited period.
Temporary access should never quietly become permanent access.
Permission sets can create consistent access for executive leadership, development leaders, development staff, marketing, volunteer management, programs, finance, administrators, and temporary event staff.
HubSpot currently supports up to 100 permission sets depending on account functionality and user permissions. A permission set still requires review when a person's responsibilities change.
Reports and dashboards can be distributed through one-time and recurring emails, file attachments, images, exports, Slack, and Google Chat. Recurring dashboard data is sent according to the permissions of the user who configured the delivery.
When results should reflect each recipient's individual access, HubSpot advises that each user configure their own recurring delivery. Once data leaves HubSpot, platform access controls may no longer protect it.
| Too broad | Too restrictive |
|---|---|
| Everyone has administrator access | Teams cannot see what they need |
| Approved reports can be edited accidentally | Staff use screenshots or spreadsheets to bypass controls |
| Volunteers see financial dashboards | Only one person can maintain reports |
| Marketing sees sensitive donor fields without need | Managers cannot verify team performance |
| Former users remain active | Routine work requires temporary admin access |
| Board reporting exposes individual records | Reporting stops when one employee is unavailable |
Review access when users are added, responsibilities change, temporary work ends, major events begin or close, integrations are installed, sensitive properties are introduced, reports are shared externally, or a security incident occurs. Add a regular review cadence as well.
HubSpot currently documents permissions for viewing, editing, creating, owning, and administering reporting assets, as well as marketing analytics, custom events, and multi-account reporting. Reports and dashboards can be private, shared broadly, or limited to eligible users and teams.
Team restrictions and some advanced controls require Enterprise functionality. Property restrictions can prevent reports from loading but should not be the only security measure. Confirm exact permissions, subscription, seat structure, and data-protection requirements before implementation.
Effective reporting permissions protect donor, financial, program, volunteer, member, and organizational information while keeping teams productive. The strongest model coordinates asset visibility, underlying CRM access, sharing, temporary roles, documented ownership, and ongoing reviews rather than relying on any single switch.