Liquid knowledge topics: build navigation with sb.containers

Use sb.containers to help customers choose the right area of your knowledge base before they search individual articles. For a B2B equipment supplier, a small set of clearly named product or service topics can be more useful than a long undifferentiated list of articles. This reference explains which topic data Core supplies and how to present it without promising access to unavailable content.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: create a clear product-knowledge menu  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.containers is a collection of public, active knowledge containers admitted to this portal. Explicit configured container IDs select those containers; otherwise a selected container supplies its children, and a page without that selection supplies roots. Each row describes a topic grouping customers browse. Use sb.container for the selected topic object. Do not assume each row contains a fully loaded hierarchy.

Some article lists and counts are populated when a template references them. The usual article-list size is ten; supported page-size handling is bounded at 250. A small topic card should show a few useful links, then take the visitor to the topic page, rather than attempting to display the entire knowledge base.

Choose the correct page and customer context

Use the knowledge landing or topic page that supplies these containers. The configured portal, division/category scope, role and language influence what can appear. An empty list can be a configuration or audience outcome; it is not a signal to expose internal topics.

Open the intended portal in Settings → Customer Portal, then choose Page templates. You need permission to administer communities or the applicable portal-edit override. Work on the existing page for this task; adding an object name to a different page does not make its records available. Keep existing forms, input names, navigation and scripts intact.

Liquid is a presentation language. Expressions inside {{ ... }} print values; statements inside {% ... %} control a loop or condition. A collection must be looped through before reading an individual row. These examples are display fragments to adapt within a working template, not replacement page templates.

Supported values and how to use them

Example: create a clear product-knowledge menu

Keep the first version simple: topic name, short explanation and a link. This gives customers a predictable route even if a topic has no image or its counts are not requested.

<ul class="knowledge-topics">
{% for topic in sb.containers %}
 <li>
 <a href="/container/{{ topic.id | escape }}">{{ topic.name | escape }}</a>
 {% if topic.description != nil and topic.description != empty %}
 <p>{{ topic.description | escape }}</p>
 {% endif %}
 </li>
{% else %}
 <li>No knowledge topics are available in this portal.</li>
{% endfor %}
</ul>

For a recurring pump issue, a topic named “Pump troubleshooting” with a description of symptoms is more informative than “Resources.” This naming recommendation helps people choose; it does not change article permissions or search ranking by itself.

Make and verify the change

1. Write down the customer task this change should improve. For example, make the correct request or relevant knowledge easier to find. Decide what should appear when there is no data.
2. Copy the current template into your approved change record before editing. Add the fragment in the correct page context without removing functional controls.
3. Choose Save Changes to save the draft, then Design to preview it. Check a populated example and an empty or signed-out example as applicable.
4. Inspect desktop and narrow-screen layouts. Test long customer names, long titles, missing optional values, readable links and keyboard navigation.
5. Use Review changes → Publish when the draft is ready. A saved draft does not update the live visitor page.
6. Open the actual portal as an intended customer and follow the full task. Verify another relevant role or customer scope where visibility differs. Record the account, page, role and outcome with the change.

Common problems and recovery

Keep the portal useful over time

Ask support agents which product or task customers confuse most often, then improve topic names and descriptions around those distinctions. Avoid building a navigation tree deeper than the information customers need to choose their next step.

Use clear labels and meaningful empty states. Do not display a raw ID when a customer needs a descriptive name, and do not describe an absent value as a service failure. After changes to portal roles, topic placement, custom fields or language coverage, revisit the relevant customer examples. A successful render alone does not establish that the instructions, links and customer visibility are still correct.

Continue learning

• Plan and publish a safe Liquid portal customization
• Show knowledge-topic breadcrumbs
• Display a topic’s article lists
• Configure the customer portal