Liquid forum navigation: display community areas with sb.forums

A forum directory helps customers choose where to read or join a product discussion. Clear community areas are especially useful when B2B customers support different products or operational roles. sb.forums supplies the configured public forum navigation; it is separate from the topic list inside one forum and from the posts in one discussion.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: make a community directory understandable  ·  Choose the right amount of activity metadata  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.forums is a list of forum rows. sb.forum is the collection of topic rows for a selected forum, and sb.topic represents a selected discussion. Keep these three levels distinct when designing a page.

Counts and last-post details are loaded when the relevant template asks for them. A new or quiet forum can have no last-post object. Design that state intentionally rather than printing empty author/date labels.

Choose the correct page and customer context

Use the community/forum navigation page supported by the portal. The directory reflects configured public forums admitted to that portal; it is not a list of private support queues or all cases.

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: make a community directory understandable

<ul>
{% for area in sb.forums %}
 <li>
 <a href="/forum/{{ area.id | escape }}">{{ area.name | escape }}</a>
 <p>{{ area.description | escape }}</p>
 {% if area.last_post %}
 <p>Latest discussion:
 <a href="/topic/{{ area.last_post.id | escape }}">{{ area.last_post.title | escape_once }}</a>
 </p>
 {% endif %}
 </li>
{% else %}
 <li>No community areas are available here.</li>
{% endfor %}
</ul>

For a customer operating several equipment families, descriptions should make it clear which area suits the question. Keep urgent case-submission routes available in the existing navigation; a community discussion should not be presented as a guaranteed monitored escalation channel unless your service process actually provides that.

Choose the right amount of activity metadata

A last-discussion link can help returning visitors rejoin a conversation. A large wall of counts can distract first-time visitors from choosing a relevant area. Start with the name and description, then add only metadata that supports a useful decision.

Do not use the absence of a recent post to declare a product unsupported. Community activity and contractual support commitments are different things. Label dates and counts accurately and keep the customer’s supported contact route clear.

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

Review forum descriptions alongside the support team’s intake guidance. Community areas should have a clear purpose and ownership so customers know when to discuss a shared question and when to open an account-specific case.

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
• Display topics within a forum
• Display a discussion and its posts
• Configure the customer portal