Liquid operators: compare values and choose portal content

Updated Wednesday, October 28, 2026 · Marc Staine

Operators let a portal template make a display decision: whether to show a knowledge section, whether a value matches a specific state, or whether a text contains a term. Use them to make the page relevant to the current customer context. They control presentation and do not replace Supportbench’s access rules.

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: distinguish signed-in knowledge guidance · Search a collection of objects correctly · Apply the example in a working portal page · Troubleshoot the common mistakes · Keep the customization understandable

Start with the practical purpose

An operator belongs in a statement such as {% if ... %}. A comparison produces a true/false decision; the block then decides what HTML to show. For a new designer, start with one clearly stated question, such as “Is knowledge enabled for this portal?” before combining several conditions.

Supportbench uses the DotLiquid .NET implementation and its own sb objects. Examples using a store’s products, cart or collections do not describe Supportbench data. Use the current page catalog to identify a real member and its type.

Syntax and supported behavior

Operator	Meaning and example
== / !=	Equal / not equal. Compare like types; a number and its quoted text representation need not mean the same thing.
> / < / >= / <=	Numeric ordering comparisons. Use them for actual numeric members, not for assuming that every count-looking string is numeric.
and	Both conditions must hold. Example: knowledge is enabled and the visitor is authenticated.
or	At least one condition holds. For complex combinations, prefer nested conditions with a clear purpose.
contains	Checks a substring in a string or a matching value in a simple collection. It does not search every property of objects in a list.

Do not import JavaScript operators such as ===, && or ||. Avoid relying on another language’s precedence or adding unsupported grouping syntax to a complicated expression; split the decision into readable nested blocks.

Example: distinguish signed-in knowledge guidance

{% if sb.knowledge_base_enabled and sb.is_authenticated %}
 <p>Review the support articles available to your signed-in contact.</p>
{% elsif sb.knowledge_base_enabled %}
 <p>Browse the knowledge available in this portal.</p>
{% else %}
 <p>Use the available support contact options in this portal.</p>
{% endif %}

The message follows the portal’s actual feature and sign-in flags. It does not promise that signing in unlocks every article. A B2B contact may still have role, company or topic restrictions.

Search a collection of objects correctly

If you have a list of article-tag objects, checking whether the list “contains” a tag name does not automatically compare each object’s name. Loop through the rows and compare the intended property, or use a supported filter such as where on a known property.

For text, contains is only a substring test. It is not language-aware search or a substitute for the knowledge-search service. Do not build security or critical routing around whether a customer’s display name contains a particular word.

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 comparison never matches	Check the member spelling, page context and value type. Remove accidental quotes around boolean or numeric literals.
contains fails on a list of tag objects	Compare each row’s name or the appropriate ID; contains does not inspect nested properties automatically.
A complicated condition gives surprising results	Break it into nested decisions and test each branch independently.
A hidden link is treated as access protection	Keep authorization in the portal’s configured server-side rules.

Keep the customization understandable

Name the operational reason for each condition. A short, explicit branch for a signed-out visitor is easier to maintain than a dense expression copied from a different Liquid product.

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?