Liquid data types: strings, numbers, booleans, lists and objects

Updated Wednesday, October 28, 2026 · Marc Staine

Many template problems are type problems: a list is treated as one record, a string count is treated as a number, or a numeric flag is treated as a boolean. This guide explains the values you will encounter in Supportbench’s Liquid templates so you can choose the right comparison, loop and output format.

At a glance

For: portal administrators and designers, including people new to Liquid. Applies to: Supportbench Core.

Start here: Settings → Customer Portal → select the portal → Page templates

Start with the practical purpose · Syntax and supported behavior · Example: create a small list and inspect its values · Recognize type differences in real Supportbench objects · Apply the example in a working portal page · Troubleshoot the common mistakes · Keep the customization understandable

Start with the practical purpose

The portal supplies a closed set of typed objects under sb. An object has named members; a collection contains rows; a string is text. Read the relevant object reference before using a field. Similar names on a list row and a detail object can have different types.

Supportbench uses DotLiquid Drops to expose approved members. This does not expose arbitrary .NET methods, database tables, HTTP requests or Shopify store objects. A missing member cannot be made available by guessing a name.

Syntax and supported behavior

Type	What it means
String	Text in quotes, such as "Your requests". A count may also be supplied as a string; inspect the object contract.
Number	Integer or decimal value without quotes, such as 5 or 2.5. Numeric zero is truthy in Liquid.
Boolean	true or false without quotes. Use for actual boolean flags such as is_authenticated.
nil	No value. It is not the string "nil" and normally prints nothing.
Collection/array	A sequence of values or objects. Loop through it or select an element; indexes start at zero.
Object/Drop	A named set of supported members, such as sb.profile or a case row. An existing default object can still have empty members.

Example: create a small list and inspect its values

{% assign steps = "Identify the issue|Read the history|Confirm the next step" | split: "|" %}
<ol>
{% for step in steps %}<li>{{ step | escape }}</li>{% endfor %}
</ol>
<p>First step: {{ steps[0] | escape }}</p>

split turns one text string into a collection. This example creates a local instructional list; it does not fetch case records. For actual cases or articles, loop through the supplied sb collection instead.

Recognize type differences in real Supportbench objects

Example	Why the distinction matters
sb.forum	A list of discussion rows despite its singular name. Read each row inside a loop.
sb.article.like_count	Exposed as a string; do not assume every count property is a numeric value.
sb.topic.forum_best_answer	A nullable numeric configuration value. Zero is not false in a bare Liquid condition.
sb.topic.forum_allow_anonymous	A nullable boolean flag, distinct from the numeric best-answer configuration.
sb.cases row sla versus sb.case.sla	The list and detail contracts differ. Use the relevant object reference and readable formatting.

The old Shopify EmptyDrop examples involving pages, collections and store handles are not a Supportbench lookup mechanism. Check a known object, meaningful member or collection size appropriate to this portal page.

Apply the example in a working portal page

Open the intended portal’s Page templates with permission to administer communities or the applicable edit override. Choose the page that supplies the object used by your example.
Preserve a copy of the existing template in your change record. Keep the working forms, routes, input names and script hooks; these examples change presentation.
Make the smallest useful edit, then choose Save Changes → Design. Inspect populated, empty and signed-out preview states as relevant.
Check punctuation, long text, optional values and narrow-screen layout. Confirm the result says what you intend, not merely that it renders.
Use Review changes → Publish for the approved design. Then verify the actual portal as the intended customer and check the full task.

Designer preview data is synthetic. A successful preview confirms neither real customer access nor the effect of a server-side workflow. Liquid cannot grant permission, edit a case or fetch arbitrary database records.

Troubleshoot the common mistakes

Problem	Correction
A value prints nothing	Check member spelling, page context, null/empty state and audience before assuming a renderer defect.
The first array item is wrong	Indexes start at zero; confirm the collection’s supplied order.
A number compares like text	Check whether the member is supplied as a string and whether your literal is quoted.
A store object such as product or cart is unavailable	Use Supportbench’s current sb object catalog.

Keep the customization understandable

Document the intended type beside complex template decisions in your change record. When a page is copied to another context, recheck its object contracts rather than assuming the same fields are supplied.

Use descriptive local variable names and keep conditions close to the content they control. Record the customer scenario tested when publishing a change. Recheck the template when its source fields, portal role rules or supported language behavior changes.

Was this article helpful?