Liquid customer case pages: show details, visible fields and activities

A customer case page should answer three questions quickly: which issue is this, what has happened, and what can I do next? sb.case supplies the authorized case detail for that page. In a B2B relationship, a clear asset, company and conversation context can prevent repeated explanations across several customer contacts, but the page must still respect the configured visibility of each field and action.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: show the issue and permitted custom-field values  ·  Display the conversation without rebuilding reply behavior  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.case is a single admitted case detail object or null when the case is unavailable in the current context. It contains descriptive fields, a custom-field descriptor list and an activity collection. It is not the same row shape as sb.cases.

Display flags such as priority_visible, asset_visible and a custom field’s visible value are part of the page contract. Preserve them when customizing. Hiding a link is not authorization, and adding a field to a template must not be treated as permission to expose it.

Choose the correct page and customer context

Use the existing case-detail page reached through /case/ and the case identifier. Preserve native reply/reopen forms, input names, attachment upload controls and customer-authentication branches. A display fragment does not implement those actions.

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 the issue and permitted custom-field values

{% if sb.case %}
 <h1>{{ sb.case.id | escape }}: {{ sb.case.subject | escape_once }}</h1>
 <p>Status: {{ sb.case.status | escape }}</p>
 {% if sb.case.summary_visible %}
 <p>{{ sb.case.summary | escape_once }}</p>
 {% endif %}
 <dl>
 {% for field in sb.case.fields %}
 {% if field.visible %}
 <dt>{{ field.name | escape }}</dt>
 <dd>{{ field.content | escape_once }}</dd>
 {% endif %}
 {% endfor %}
 </dl>
{% else %}
 <p>This request is not available in the current customer context.</p>
{% endif %}

This is a read-only display example. required and list_values matter when the native page builds editable controls, but rendering them in a definition list does not implement field editing. Keep the existing type-aware control and save behavior if customers are allowed to update a field.

Display the conversation without rebuilding reply behavior

Use the supplied activity content in its intended HTML container, while escaping ordinary metadata. The authorized activity list and server-side page behavior determine what a customer can see. Do not substitute an internal agent activity query or infer that every case activity is public.

{% for activity in sb.case.activities %}
 <section class="case-activity">
 <h2>{{ activity.subject | escape_once }}</h2>
 <p>{{ activity.created_by | escape }} · {{ activity.created | ldate | escape }}</p>
 <div class="activity-body">{{ activity.content }}</div>
 {% for file in activity.attachments %}
 <p><a href="{{ file.path | escape }}">{{ file.name | escape }}</a>
 ({{ file.size | format_bytes | escape }})</p>
 {% endfor %}
 </section>
{% endfor %}

Keep the existing reply and reopen controls. can_reopen describes availability in the current state; printing a button with that label does not create a working, authorized reopen operation.

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

Test the full customer conversation: identify the case, read its history, download an authorized attachment and use any permitted next action. Include contacts with different roles so the page remains useful without exposing internal information.

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 the customer request list
• Understand agent Case View and collaboration
• Configure customer roles
• Configure the customer portal