Liquid customer case counts: use sb.cases_summary with the correct scope

A request summary can give a customer a quick sense of their open and closed support work. sb.cases_summary supplies contact-scoped counts for that purpose. Accurate labels matter: a contact’s summary is not automatically the same as all requests their company can access, and a community-related count is not a complete forum participation report.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: label personal request counts accurately  ·  Investigate a count mismatch in the right order  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

case_open_count counts the contact’s applicable cases with a positive status, excluding the trash/forum categories used by this summary. case_closed_count uses closed status zero with those exclusions. The summary is built for the current account and contact, rather than a support-team or company-wide reporting scope.

topic_count uses the contact’s forum-post-backed case relationship in this implementation. It should not be labeled as every topic the person has viewed, followed, or participated in. Without valid customer context, a default zero summary may be returned; zero alone is not proof of a successfully authorized empty account.

Choose the correct page and customer context

Use a signed-in customer page that supplies current contact context. Show a sign-in state first for anonymous visitors rather than presenting default zeros as their personal history. Compare counts only with lists that use the same scope.

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: label personal request counts accurately

{% if sb.is_authenticated %}
 <section aria-label="Your request summary">
 <p>Your open requests: {{ sb.cases_summary.case_open_count }}</p>
 <p>Your closed requests: {{ sb.cases_summary.case_closed_count }}</p>
 </section>
{% else %}
 <p>Sign in to see your request information.</p>
{% endif %}

Keep the existing request navigation beside the summary. If that navigation opens a broader company list for a privileged contact, label the difference explicitly instead of suggesting that these personal counts must match every row the contact can access.

Investigate a count mismatch in the right order

1. Confirm the signed-in contact and account. A colleague’s profile is a different scope.
2. Identify the list being compared: personal requests, company requests, a filtered list or a paged slice.
3. Check the open/closed definition and exclusions. A selected status filter is not necessarily the same as every positive status.
4. Check whether the list includes authorized secondary-contact or company relationships that the summary does not count in the same way.
5. If a mismatch remains, record the contact, list/filter, expected case IDs and actual counts for investigation through an approved support channel. Do not change access rules simply to make two different scopes match.

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

Use these counts to orient the current contact. For weekly account reviews or operational commitments, use the appropriate view/report with its explicitly defined scope, dates and status criteria.

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
• Understand customer request-list scope
• Build views for operational and account reviews
• Configure the customer portal