A dashboard can look finished before anyone has checked whether it answers the question the business asked. A plausible total and a polished chart are not enough to accept the underlying report.
We recommend agreeing on a small acceptance pack before the report is built. It should connect the business question to the definition, records, calculation and evidence used to approve the result.
TLDR: Test the report against an agreed population and a controlled dataset with known outcomes. Check included records, exclusions, date boundaries, missing data and access. Retain the exact report configuration and expected result, with unresolved exceptions visible at handover.
Define what HubSpot reporting acceptance tests must prove
The acceptance pack should let another authorized person reproduce the report's meaning. They need the business question, the underlying records, the calculation and the access conditions, not just a dashboard screenshot.
Write the specification before comparing the result. If the definition changes during the handover, version it and rerun the affected tests. A passed test applies to the configuration actually checked.
Name the business decision
Describe who uses the report and what action it supports. A sales team reviewing stalled deals needs different evidence from customer service teams reviewing unresolved tickets.
Do not accept “better visibility” as the whole requirement. State what the viewer should be able to determine and which uncertainties the report cannot resolve.
Name the unit being counted
Choose whether the report counts contacts, companies, deals, activities, submissions or another defined unit. Include the aggregation rule.
A dataset with three contacts associated with one company can produce different valid totals depending on the question. The acceptance test must establish which total the business intends to use.
Build an acceptance matrix before the agency handover
Use a matrix that links each requirement to an expected result and evidence. Keep the status blank until the test is actually executed.
| Test area | Example question | Evidence to retain |
|---|---|---|
| Population | Are the intended records included? | Included identifiers and exclusion reasons. |
| Calculation | Does the selected aggregation match the definition? | Independent calculation with stated inputs. |
| Dates | Are start and end boundaries applied correctly? | Boundary records and timezone notes. |
| Relationships | Does the expected association control inclusion? | Related record identifiers and relationship rule. |
| Missing data | Are unknown values visible? | Exception list and approved treatment. |
| Access | Can the intended viewer use the report appropriately? | Role, sharing arrangement and observed result. |
| Delivery | Does the report work where people will use it? | Dashboard or report link and actual viewer check. |
| This is a recommended test design. It is not a statement that these checks have been run in your HubSpot account. |
Decide the expected result before inspecting the chart
A test with no expected outcome can become an exercise in approving whatever appears. Write the expected records and total first.
Where possible, calculate the result independently from a small controlled dataset. Avoid using another copy of the same unverified report as the only reference.
Keep the test account or environment appropriate
Use an approved test environment or another authorized method that does not trigger unwanted business activity. Synthetic contacts can still activate workflows or messages if placed in a production process without controls.
Record the environment and any excluded actions. Do not assume a label such as “test” automatically prevents real effects.
Build a small dataset with deliberate exceptions
Use synthetic records or another approved test method. Include a normal qualifying case, an excluded case, a boundary case and a record with missing information. Write the expected result before inspecting the chart.
Hypothetical example: The report should total the known amounts of closed-won deals with a close date in January. An included deal with no amount must appear in an exception review. All records and values below are fictional, with amounts in one unspecified test currency.
| Deal | Status and close date | Amount | Expected treatment |
|---|---|---|---|
| Example A | Closed won, January 15 | 1,000 | Include in the known-amount total. |
| Example B | Closed won, January 31 | 2,000 | Include at the end-of-period boundary. |
| Example C | Open, January 20 | 500 | Exclude because the status does not qualify. |
| Example D | Closed won, February 1 | 800 | Exclude because the date is outside the period. |
| Example E | Closed won, January 10 | Missing | Flag the missing amount as an unresolved exception. |
| The expected known-amount subtotal is 3,000 from A and B. That subtotal can be correct while E still prevents acceptance of a complete revenue figure. The test must check both the calculation and the exception treatment. |
Test more than a plausible total
A total can be correct while the record selection is wrong. Include cases that expose offsetting errors, duplicated associations and unexpected exclusions.
Check a normal qualifying record
Start with a simple record that clearly meets the definition. Confirm the identifier, relevant properties and the intended date.
This establishes a readable baseline. If the normal case fails, resolve it before interpreting more complicated edge cases.
Check an explicit exclusion
Add a case that looks similar but should not qualify. It may have a different stage, date, owner or required relationship.
Record why the exclusion is expected. That explanation helps distinguish a reporting defect from a disagreement about the business rule.
Check duplicate and multiple-association cases
If a report joins data sets, include a record with more than one relevant relationship. Determine whether the expected unit is a distinct record or an association row.
Check both the total and the identifiers. A duplicated deal amount can be difficult to notice in a large dashboard even when a small controlled case makes it obvious.
Check missing information without hiding it
Test a missing amount, missing classification or missing relationship where those inputs matter. Decide whether the case belongs in an exception report, an excluded population or another explicitly defined category, and make missing-data feedback visible for review rather than hiding it in the total.
Do not make zero the default answer to every missing value. An unknown amount and a confirmed zero amount are different business facts.
Test the dates your team actually uses
Define the event date and timezone before writing boundary cases. A deal-created view and a deal-closed view answer different questions, even when both display a monthly total.
Test the first and last included dates
Include a qualifying record at the start and end of the period. Add another immediately outside the boundary.
Use the actual date property and report behavior. Do not invent a timezone conversion or assume every date-only and datetime field is handled identically.
Test dashboard filters as well as report filters
Ask the intended viewer to use the report in its normal dashboard context. Check whether a dashboard filter changes the population or period.
Retain evidence of the effective settings. A report that passes in isolation can still confuse viewers when the surrounding dashboard changes what they see.
Allow for the documented refresh behavior
Check how the selected report type updates before treating a delayed result as a defect. HubSpot describes different report types and refresh behavior in its current custom-report documentation. Review custom-report behavior
Record when the source record changed and when the report was observed. Retest after the applicable refresh window instead of repeatedly editing the source to force a result.
Match tests to the reporting use case
Use the same acceptance method across departments, but change the records and expected outcomes to match the business question and the specific HubSpot reporting tools or other reporting tools involved.
Sales team reporting
For a deal report, confirm the stage, date, amount definition and relevant relationships. Include open, closed and excluded cases where they affect the specification.
For sales enablement or activity reporting, define the activity being counted. A created task, a completed task and a completed customer interaction should not silently become the same measure.
Marketing reporting
For email campaigns, website activity or lead reports, identify the unit and collection method. Confirm whether the measure counts events, submissions, sessions or unique records. Funnel reports in HubSpot also help analyze customer journey stages when validating lead or conversion reporting.
If the report combines CRM data with another source, document the join and the missing-data behavior. Marketing automation activity alone does not establish a completed business outcome.
Service reporting and customer satisfaction surveys
For customer satisfaction surveys, state the response population and the treatment of unanswered surveys. Do not compare unlike measures under a generic “customer satisfaction” label.
Customer satisfaction scores, net promoter score and ticket-resolution metrics use different definitions. Include the relevant source and calculation in the acceptance pack rather than assuming the chart title explains them.
Verify permissions with the intended user
Check both access to the report and access to the underlying data. HubSpot documents that dashboard sharing can control report access and that report access does not override underlying record or field permissions. Manage report access
Test the actual delivery path
Have an authorized viewer open the saved report or dashboard link through the normal process. Record the role and the observed result.
A Super Admin seeing a complete chart does not prove that sales reps or service users will see the same data. Partial data may reflect an intended permission boundary rather than a broken calculation.
Do not broaden access to make a test pass
If a viewer cannot access required information, identify the missing permission and the business requirement. Route any permission change through the appropriate owner.
Keep the access issue open until the approved arrangement is verified. A reporting handover is not blanket authorization to expose all CRM data.
Define how exceptions affect acceptance
Give each failed test a clear disposition: correct the configuration, correct the source data, revise the requirement or accept a documented limitation.
Separate defects from change requests
A defect means the implementation does not match the agreed requirement. A change request means the business wants a different requirement.
Record that difference. Otherwise, an agency may keep changing filters while the business believes it is waiting for a stable report.
Retest the affected configuration
After a correction, rerun the failing case and any related cases that could be affected. Preserve the earlier failure and identify the revised configuration.
Do not carry a passed status from an earlier version into a materially changed report. The evidence should show what was checked after the change.
Questions to answer before accepting the handover
Is a screenshot enough?
No. Keep the report identifier, configuration, expected result and record-level evidence alongside the screenshot. The screenshot shows what appeared; the other evidence explains why the result is credible.
Does every report need a large test dataset?
No. A small, deliberately designed dataset can expose important errors. Choose cases that cover the actual rules, boundaries and relationships instead of adding records with no testing purpose.
A small test does not prove every future record will behave correctly. It establishes evidence for the cases and configuration you checked.
Who owns the report after the agency leaves?
Name an internal business owner for the definition and an operational owner responsible for maintaining reporting practices across the organization. They may be the same person in a small team.
Include the review trigger for future changes, where the acceptance evidence is stored and how users report a problem. Ownership should also preserve the team's ability to make data driven decisions after the agency handover. A handover is incomplete if nobody can explain or maintain the report afterward.
Hand over the evidence and ownership
Retain the question, definition, report identifier, configuration, expected and observed results, and unresolved exceptions. Connect the training through HubSpot onboarding and training and the technical review through HubSpot operations.
Official documentation checked September 7, 2026. Test records, dates and amounts are synthetic, and the examples do not represent executed portal tests or actual revenue.
