HubSpot index pages are the working screens where users browse, filter and manage records such as contacts, companies, deals and tickets. Index page types define the structure and purpose of those screens, while tabs provide named views of different subsets of the same record type.
The best configuration is not the one with the most tabs or the most detailed filters. It is the one that helps each user answer a practical question quickly: which records need attention, who owns them, what state are they in, and what should happen next?
Use index page types for genuinely different record workflows. Use tabs for repeatable views within one workflow. Before changing settings, define the business states, ownership rules and decisions the page should support. Tool configuration should follow that operating logic, not replace it.
What HubSpot index page types and tabs control
An index page is a list-oriented workspace for a HubSpot object. An index page type gives that workspace a defined purpose, usually around a record object and the way a team needs to work with it. Tabs then separate useful record populations within that workspace through saved filters or views.
For example, a deal index page might contain tabs for active deals, deals owned by the current user, deals awaiting approval and recently closed deals. These are not four different types of business data. They are four operational questions about the same deal workflow.
A CRM tab should represent a repeatable business question, not a filter that someone happened to save once.
The exact configuration options available in HubSpot can vary by account, object, subscription and product updates. Treat the navigation labels in this guide as a planning model, then confirm the current interface and permissions in your HubSpot portal.
When to create an index page type versus a tab
The distinction between an index page type and a tab matters because each adds a different kind of complexity. Creating too many page types can fragment navigation. Creating too many tabs can make one page difficult to understand.
When the workflow is materially different
Create a separate page type when the object, ownership model, required fields, lifecycle or team process is different. A service ticket queue and a sales deal pipeline should not be forced into the same working view.
When the workflow is the same
Use a tab when users work with the same object and process but need a different, predictable slice of records. Examples include open versus closed, assigned to me versus assigned to my team, or priority versus standard.
A useful decision rule is simple: if users need different actions, ownership rules or definitions of progress, consider a separate page type. If they need different visibility into the same process, a tab is usually more appropriate.
Start with the business questions
Before opening HubSpot settings, write down what users need to know and what they need to do from the page. This prevents the configuration from becoming a collection of technical filters with no operational purpose.
- Identify the user group. Clarify whether the page is for sales representatives, sales managers, service agents, operations users or another group.
- Define the record population. Decide which object and lifecycle states belong on the page. Avoid relying on vague labels such as “important” unless the property and its meaning are documented.
- Define the next action. State what a user should do after finding a record. A useful view should help someone prioritize, qualify, assign, update or resolve work.
- Define ownership. Decide whether records are owned by an individual, team, territory, queue or another accountable role.
- Define the exception. Identify records that need attention because they are overdue, unassigned, stalled or missing required information.
A view can be technically accurate and still operationally weak. If users cannot tell what requires action or who owns the next step, better filtering has not solved the workflow problem.
Planning a HubSpot index page
Once the business questions are clear, map the page around a small number of meaningful views. A practical page often includes a default view, a personal work queue, a team view and an exception view. The right number depends on the workflow, but every additional tab should earn its place by supporting a recurring decision.
How to configure index page types and tabs in HubSpot
The administration path and available controls may change, so use the current HubSpot settings interface for the final clicks. The configuration sequence should remain broadly similar.
1. Confirm permissions and account context
Start with an administrator or user who has the required CRM customization access. Confirm that you are changing the intended HubSpot account, object and environment. A configuration that is correct for one team or portal may not be appropriate for another.
2. Select the record object
Choose the object that users need to browse, such as contacts, companies, deals, tickets or a custom object where available. Make sure the selected object has the properties required to distinguish work states and ownership.
3. Set the page purpose and base scope
Give the index page a clear name that communicates both the object and the workflow. Then apply broad conditions that should be true for all records on the page. Base filters should provide a stable boundary, while tabs should provide the useful variations inside that boundary.
4. Create tabs around repeatable decisions
Use labels that describe the record set in language users already understand. “My open deals” or “Unassigned priority tickets” is usually more useful than an internal label such as “View 3.” Keep filter logic visible in documentation so an administrator can understand why the tab exists.
5. Set the order and default view
Place the most frequently used or most important working view first. The default tab influences daily behavior, so it should help users begin with the records that require attention rather than a broad, low-value list.
6. Test the result as a real user
Review the page with users from each relevant role or team. Check whether expected records appear, whether excluded records are genuinely out of scope, whether ownership is clear and whether the user can take the next action without rebuilding the filter.
Design rules for reliable CRM views
Use controlled properties to represent business states
Filters are only as reliable as the properties behind them. If a tab is called “Ready for handoff,” the underlying criteria should describe a real state, such as required information being complete and ownership being assigned. Avoid using free-text notes or inconsistent labels as the primary control for important views.
A CRM stage should represent a meaningful business state, not simply an activity someone performed. Sending an email, creating a task or opening a record does not necessarily mean that the underlying customer or opportunity has changed state.
Make ownership visible
Every working view should make accountability clear. Depending on the process, that might be an owner, team, queue or escalation role. A tab showing overdue records without an accountable owner creates visibility without resolution.
Separate workload views from reporting views
A user work queue is designed to support action. A management view may be designed to inspect volume, age, conversion or exceptions. These purposes can overlap, but they should not be assumed to be identical. A view that is useful for a daily queue may not provide a stable basis for performance reporting.
Limit duplicate logic
When several tabs use slightly different versions of the same filter, users may lose confidence in which one is correct. Centralize definitions where possible and document the intended difference between similar tabs. If nobody can explain why two views differ, one of them may not be needed.
The purpose of a CRM view is not to expose every possible record segment. It is to reduce the time between seeing a business state and taking the correct next action.
Example: designing a deal index page
Consider a hypothetical sales team with one HubSpot deal pipeline. The team needs to manage active opportunities, identify deals with no recent activity and separate opportunities that are ready for commercial review.
A sensible page design might use one deal index page with these tabs:
- Active deals: deals in open pipeline stages with an assigned owner.
- My active deals: the same working population restricted to the current user.
- No recent activity: open deals that meet a documented inactivity condition.
- Ready for review: deals that meet the agreed criteria for a manager or commercial review.
- Unassigned deals: open records that need ownership before sales work can proceed.
This design is stronger than creating a separate page type for every sales team question because the underlying workflow is still the same. The tabs support different decisions without hiding the common pipeline context.
Governance, maintenance and troubleshooting
Index pages and tabs should be treated as part of CRM governance, not as permanent interface decoration. Assign an owner for reviewing the configuration and record the purpose, audience, filter logic and expected action for each important page.
- Does the name describe the records users will actually see?
- Does every filter correspond to a documented business rule?
- Can users identify who owns the next action?
- Are the records in the default view still the right starting point?
- Do the filters rely on properties that users update consistently?
- Is the tab still used often enough to justify its place?
- Would changing the view alter a downstream workflow, report or handoff?
When users report that a view is wrong, inspect the property values and business definitions before changing the filter. The problem may be incomplete data, inconsistent stage usage or unclear ownership rather than a page configuration error.
HubSpot configuration is most effective when it supports a wider CRM operating model. If the issue involves inconsistent pipeline design, disconnected processes or unclear data ownership, HubSpot consulting can help connect the interface design to CRM architecture, automation and reporting. For broader system ownership and data model questions, CRM consulting can provide a wider process and governance perspective.
What good index page design looks like
A well-designed HubSpot index page does more than make records easier to find. It makes the operating rules visible. Users can see which records belong in their queue, what state each record is in, who owns the next step and which exceptions need attention.
Start with process definitions, then configure the smallest useful set of page types and tabs. Review the result with real users, remove views that do not support a decision and update the design when the underlying workflow changes. More tabs and more tools do not automatically create a better CRM. Clear states, visible ownership and reliable data do.
Frequently asked questions
What is a HubSpot index page type?
A HubSpot index page type is a configured list workspace for browsing and managing records of an object such as contacts, companies, deals or tickets. It defines the page's purpose and broad scope, while tabs can show filtered subsets within that workflow.
What is the difference between a HubSpot index page type and a tab?
An index page type is appropriate for a distinct object or workflow. A tab is generally a filtered view within the same workflow, such as open records, records assigned to the current user or records requiring attention.
How many tabs should a HubSpot index page have?
There is no universal number. Create a tab only when it supports a recurring business question or action. If users cannot explain the purpose of a tab, or several tabs contain nearly identical records, simplify the page.
Why are HubSpot tabs showing unexpected records?
Unexpected records may result from incorrect filter logic, inconsistent property values, unclear stage definitions, ownership changes or differences in user access. Check the underlying data and business rule before changing the tab.
How should HubSpot index pages be governed?
Assign an owner for the configuration, document each page's purpose and filters, test changes with representative users and review unused or duplicated tabs periodically. Changes should also be checked for effects on workflows, reports and handoffs.
Need a clearer HubSpot working model?
If your HubSpot views, ownership rules or pipeline states are difficult to manage, ConsultEvo can help connect the CRM interface to a cleaner operating process, data model and automation plan.
