Liquid customer request lists: display sb.cases with account context

A customer request list should help a contact find the correct issue, understand its state and open the history. In B2B support, the company, affected asset and people involved can be as important as the subject. sb.cases provides authorized case-list rows for the current portal context; it does not grant a customer unrestricted access to every company case.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: show a readable request list  ·  Explain dates and service commitments carefully  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.cases is a collection of case summary rows, commonly used on the /cases page. The server determines which personal, company, administrator or secondary-contact relationships are admitted. The current page’s scope and paging still apply. A Liquid loop does not fetch the whole account.

The case-list row differs from the detailed sb.case object. For example, the list’s sla member is a string, while the detail object has a date-shaped SLA member. Use the correct reference for the page you are editing.

Choose the correct page and customer context

Use the customer request-list template and preserve its existing filters, paging, sorting and navigation. Test ordinary contacts and any company-level role your portal supports, since their permitted lists can differ.

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: show a readable request list

<ul class="customer-requests">
{% for request in sb.cases %}
 <li>
 <a href="/case/{{ request.id | escape }}">{{ request.id | escape }}: {{ request.subject | escape_once }}</a>
 <p>Status: {{ request.status | escape }}</p>
 </li>
{% else %}
 <li>No requests are available in the current list. Check the existing filters and account context.</li>
{% endfor %}
</ul>

For a customer with similar faults at several sites, a recognizable subject and case identifier can prevent the wrong request being opened. Keep the list compact enough to scan. Do not add every technical field just because it is available.

Explain dates and service commitments carefully

A modification timestamp can change for reasons other than a new customer-visible reply. Label it “Updated” or another accurate term rather than “Last response” unless you are using a field that actually measures that event.

Likewise, an SLA display value is not a complete explanation of the customer’s service commitment. Do not compute a new compliance percentage from arbitrary dates in Liquid. Preserve the supported deadline display and point customers to the agreed support process for interpretation.

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

Agree on the few columns customers need to recognize and prioritize their requests. Recheck the experience for multiple contacts in one organization so a convenient account view does not imply broader access than the configured role provides.

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 a detailed customer case
• Compare contact-scoped request counts
• Configure customer role visibility
• Configure the customer portal