Sections

Categories are the spine of your Knowledge Base — every article lives in exactly one. Sections are something different. A section is a secondary grouping that pulls articles from anywhere in your KB, based on rules you set or a manual list, and renders them as their own block on the public site.

You’d use a section for things like:

• Most popular — the five articles with the most views.
• For developers — articles tagged developer regardless of which category they’re in.
• What’s new — articles published in the last 30 days.
• Returns and refunds — a curated list of articles spanning Billing and Returns categories.
• Sales reps — articles tagged for the sales team, drawn from across the KB.

A single article can appear in many sections. Sections never replace a category; an article still lives in its primary category. Sections are about surfacing it from a different angle.

How sections fill themselves

A section can use rule-based auto-fill, a manual list, or both — curated articles always appear first:

• Rule-based auto-fill — Section pulls articles matching filters you set: categories, subcategories, tags, sort order, limit. Updates automatically as articles match. — When the membership should evolve as you add content — “Articles tagged troubleshooting”, “Newest 10 articles”, “Everything in Billing or Returns”.
• Manual list — You pick specific articles by ID. Updates only when you edit the section. — When the curation matters more than the rule — “Five articles I want featured on the home page”.

Admins can also tie a section to one or more enabled markets. This is an internal organizing label for the builder: when you configure the section, category and tag pickers are limited to market-specific items that match those markets. It does not create a new customer-facing visibility rule, and it does not change how the section auto-fills on the public Knowledge Base.

Rule-based sections support these filters:

• Category IDs — limit to articles in specific categories.
• Subcategory IDs — limit to articles in specific subcategories.
• Tag IDs — limit to articles tagged with at least one of the chosen tags.
• Sort mode — newest, oldest, alphabetical.
• Limit — cap on how many articles render in the section.

Combine them: “Tagged troubleshooting AND in the Billing category, sorted newest first, limit 5.”

Where sections appear

A section can be rendered on the public help center via the Section Grid, Section List, or Section Bar blocks in the layout builder. Each block lists your published sections and links to each section’s page. You can also have a section that exists in your config but isn’t rendered anywhere — useful as a draft.

Every section has its own page at /section/<slug> on your help center. Articles still link to their category. Show in Navigation controls whether a section appears in the Section Bar block and the sections sidebar.

Overview articles

A section can have an overview article — an article shown above the list as introduction or context. Useful when a section is a curated topic (“Returns and refunds”) that benefits from a paragraph of framing before the article list.

Sections vs. tags vs. roles

These three are easy to confuse:

• Tags are labels on articles. They’re cross-cutting and customers can filter by them.
• Sections are groupings of articles. Customers see them as headed blocks on the help center.
• Roles are audience groupings for articles. Public role pages and the ?role= filter use them to organize articles for a specific audience view.

A tag is a property of an article. A section is a way of presenting a set of articles. A role is the audience view an article belongs to. Use tags to describe articles, sections to display them, and roles to organize them for an audience.

Where to go next

• Build a section: Create a section
• Render it on the public site: Customize the public portal
• Reference for the available blocks: Portal blocks reference