Gainsight Customer Communities expands category hierarchies to five levels

Gainsight adds deeper native structure for communities and knowledge

Gainsight's September 17 Customer Communities release notes say Community and Knowledge Base structures now support up to five nesting levels out of the box. Admins can nest Sections inside existing Sections, and the product extends recursive navigation through the mega menu, breadcrumbs, sidebar tree and section overview pages. Existing structures do not require reconfiguration simply because the deeper hierarchy is available.

Gainsight also adds an important caution: although five levels are supported, it recommends capping structures at three levels, or four at most. That warning is operationally useful. The release expands what the product can represent, but more representational depth does not automatically make content easier for customers to find, understand or maintain.

Sources: Gainsight Q3 2026 Customer Communities release notes

Treat taxonomy depth as a customer journey decision

Before adding levels, map the questions customers actually bring to the community or knowledge base. A hierarchy can help when the product itself has stable parent-child concepts, such as product family, module, capability and task. It can hurt when internal org charts, ownership boundaries or marketing labels are projected onto users who do not share that mental model.

Test representative paths from a search engine, in-product help link, community homepage and support handoff. A user entering at a deeply nested article should still understand where they are, how to move to a sibling topic and what broader section owns the content. Breadcrumbs can expose the path, but they do not repair ambiguous naming or duplicate categories.

Deeper trees increase the cost of ownership changes

Every additional level creates more places where stale content, duplicate definitions and unclear ownership can accumulate. Record a business owner and review cadence at the section level, not only at the article level. When a product team reorganizes modules or renames a feature, the knowledge hierarchy should have a documented migration path rather than leaving old branches in place indefinitely.

Use stable identifiers where integrations depend on the structure. If analytics, in-product links, support macros or external documentation refer to a section, confirm whether moving or nesting that section changes its URL or reference. Preserve redirects or mapping where needed and test the customer journey after structural changes, not only the admin interface.

Search analytics should decide whether the new depth helps

A deeper hierarchy should improve one of a few observable outcomes: customers reach the intended content with less confusion, support teams can maintain ownership more clearly, or content analytics become easier to interpret. Measure search terms with no useful result, repeated navigation between sibling branches, exits from overview pages, article feedback and support contacts that follow a knowledge visit.

Do not treat a lower ticket count as proof that the hierarchy caused successful self-service without a controlled definition. Content changes, product releases, seasonality and support volume can all move together. Direct evidence such as search-to-article paths, failed queries, feedback and sampled support journeys is more useful for evaluating the structure itself.

Keep the hierarchy shallower than the organization chart

Gainsight's own recommendation to stop around three or four levels is a useful default. A fifth level can be reserved for product lines that genuinely need another layer, rather than becoming the standard template. When administrators need repeated five-level paths to separate ownership or audience, consider whether tags, filters, search metadata or a different entry page would represent the distinction more clearly.

The operating model should name who can create a new top-level section, who can add subcategories, who owns naming conventions and how duplicate or empty branches are retired. Without those rules, additional depth makes it easier to encode local preferences and harder to keep one customer-facing taxonomy.

What to verify in the release

Create a test branch that uses the full supported depth and inspect the mega menu, breadcrumbs, sidebar, overview pages, mobile navigation, keyboard behavior and direct article entry. Move one section, rename another and verify what changes in URLs, analytics and internal links. Then compare that deep structure with a three-level alternative using the same content set.

The release is useful for complex knowledge estates, but the best structure may still be shallow. RevOps, CS Ops and Support Ops should use the new capability as an information-architecture option, not a target. The right depth is the smallest hierarchy that lets customers find content and lets operators own, measure and change it without losing context.