How do you use the HubSpot custom report builder?

Every report in your portal draws on records your team created and the links between them. The builder arranges that data into a report. It cannot invent a field nobody filled in or a link no integration wrote. So the first hour of report work happens away from the builder, with the person who will read the result.

The question the report must answer

A report request often arrives as a chart idea, such as pipeline by source. A chart idea leaves out who reads it, what decision it feeds and which records count. Write the request as a question whose answer is a number or a short list.

• How many deals created this quarter came from webinar attendees?
• What share of renewals closed before the contract end date?
• Which campaigns produced the meetings that turned into closed deals?

Next to the question, write down 3 facts about it.

• Who reads the report, and how often.
• The decision the number feeds.
• A number someone already trusts, such as a finance total or a count from your billing system.

Then define each term in the question. Sales and marketing often attach different meanings to one word, such as lead, closed or this quarter. A written definition decides which records the filters keep. It also gives Step 3 something to test against.

A written question also shortens the build. The admin knows which records to check and when the work is done. Each step below names an owner and a check, and the table puts the plan on one page.

Step	Owner	Check
1. Check objects and associations	HubSpot admin or RevOps lead	Recent records carry each link
2. Build the report	Person who ran Step 1	Each filter matches a definition
3. Test the numbers	Builder plus the number’s holder	Totals match or gaps have causes
4. Put it on a dashboard	Leader who asked	Report comes up in its meeting

Step 1. Check the objects and associations behind the question

Your HubSpot admin or RevOps lead owns this step. Break the question into the record types it touches. A question about which campaigns produced closed deals touches campaigns, contacts and deals. The report needs a path from each record type to the next one.

For each link on that path, write down 4 facts.

• Whether the relationship exists in your data model.
• How many recent records carry it, from a sample you open by hand.
• What writes the link, such as a rep, a workflow, an import or an integration.
• Which property holds each value the report will show, and who keeps it filled.

Suppose, as an imagined case, that marketing wants pipeline by campaign. Reps create deals without associating the contact who attended the campaign. The campaign never reaches the deal, so the report files that pipeline under no campaign. The builder works as designed, and the total still misleads.

A link that exists on paper but sits empty on most records produces a report that undercounts. Close the gap before you build. Add the association, add the property or change the process that should write it. For older records, a one-time cleanup fills the link where the source data allows it.

Links that an integration creates need their own check. Find the field that triggers each link, and confirm it fills on records from every source system.

Some questions need a record type your portal does not hold yet. Chris built a custom solution for storyarb that tracks MRR through upgrades, downgrades, discounts, contract changes and retention. A report on revenue movement needs records like those before it has anything to count. The storyarb case study describes that build. Our custom builds cover custom objects, associations, property sets, pipelines and board views designed around your data model.

The step passes when each link on the path exists and the sample of recent records carries it.

Step 2. Build the report in the custom report builder

The person who ran Step 1 builds the report, because they know where each gap sits. Work from the written question and its definitions, in this order.

1. Start from the record type your question counts. A question about deals counts deals.
2. Add only the related record types on the path from Step 1.
3. Choose the properties the reader needs to see.
4. Set filters that match each written definition, including the date range and the pipeline.
5. Pick the chart that answers the question, such as a single number, a trend or a breakdown.

A single number suits a question with one answer. A trend suits a question about change over time. A breakdown suits a question that compares sources, owners or regions.

Every extra record type adds a link that can drop records. Keep the report to the path the question needs. A second question belongs in a second report.

Name the report after its question, so the next viewer knows what it answers. Store the written definitions with your team’s process notes. A report with no definition beside it gets copied and edited until nobody knows which version is right.

This guide leaves the builder’s screens, its data source limits and the HubSpot subscriptions that include it to HubSpot’s current documentation. Check that documentation before you plan a report that joins several record types.

The step passes when the person who built the report reads each filter aloud against its written definition and the 2 match.

Step 3. Test the numbers against a known source

The person who built the report owns this step, together with whoever holds the trusted number. That person often sits in finance or billing. A report that skips this test reaches a dashboard with errors nobody has found.

1. Pick a closed period, such as last month, so neither number keeps moving.
2. Pull the trusted number for that period from its own system.
3. Run the report for the same period with the same definitions.
4. Export the records behind each number and match them by record ID.
5. Trace each record that appears on one side only to its cause.

Gaps trace back to causes like these.

• A record lacks the association the report depends on.
• The report filters on one date, such as create date, while finance uses another.
• Test records or duplicates sit inside the filter.
• A deal stage carries a different definition in each team.
• A rep moved a record to another pipeline after the period closed.

A gap can stay when you can name its cause and the reader accepts it. Write the cause next to the report’s definitions. Keep the exported records from this test, since they become the baseline for the next comparison. Run the test again after any change to a workflow, import or integration that writes a property in the report.

The step passes when the totals match, or when each difference has a cause the reader accepts.

Step 4. Put the report on a dashboard people use

The leader who asked for the report owns this step. A report earns its place when a decision depends on it.

• Group reports by the meeting they serve, such as the pipeline review each week.
• Open the dashboard on screen during that meeting.
• Give each dashboard one owner who answers questions about its numbers.
• Retire reports that no meeting uses.

A dashboard nobody owns gets skipped, and its errors go unnoticed. Review each dashboard every quarter with its owner. Remove the reports no meeting used, and fix any number a reader questioned.

Faster reporting changes what a team can act on. Chris worked with Levrx’s team on how HubSpot could support its member engagement, workflows, data movement and reporting. Levrx now sees campaign results within 24 hours of a send, down from waits of 2 to 4 weeks. The Levrx case study covers that work.

Readers trust a dashboard they learned on their own records. We train teams in their live portal, with their real data and pipelines. We also leave recorded walk-throughs and written documentation that new hires can use later.

The step passes when the owner confirms the report came up in the meeting it serves during its first month.

What goes wrong with custom reports

A broken report points to a problem in the data or the process behind it. We find where each problem starts before we change anything.

• The question never got written down, so each viewer reads the chart a different way.
• A link exists on new records only, so older records drop out of the totals.
• An integration overwrites a property the report depends on.
• Duplicate records count one company or deal twice.
• Copies of the report drift apart until several versions disagree.

Integrations do their damage out of sight. Nobody sees an overwrite until a total looks wrong. Any new build starts after our audit of your current integrations, which checks for gaps, errors and silent failures.

When the fix belongs in the portal, its size sets the timeline. Our service pages give these typical ranges.

Fix behind the report	Typical range
A single workflow	Days
Audit and cleanup of one hub	3 to 4 weeks
Automation audit and build-out	3 to 6 weeks
Enterprise portal across Marketing, Sales and Service hubs	8 to 12 weeks
Custom build of objects and associations	8 to 16 weeks

Portal optimization starts with a diagnostic of the data model, properties, workflows, integrations, reporting and user adoption. We then fix the issues with the most impact first.

Before the next report request reaches your admin, write its question, definitions and trusted number on one page. That page becomes the test the report must pass in Step 3.