Liquid conditions: write useful signed-in, empty and fallback states

Updated Wednesday, October 28, 2026 · Marc Staine

A good portal page remains useful when a customer is signed out, has no matching requests or lacks an optional company value. Conditional tags let you explain those situations instead of leaving blank headings or broken links. This guide shows how to choose a clear branch and preserve a useful next step.

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: show company context without an empty label · Use case/when for a small presentation choice · Apply the example in a working portal page · Troubleshoot the common mistakes · Keep the customization understandable

Start with the practical purpose

The opening tag starts a decision and the closing tag ends it. if displays a block when its condition holds; elsif tests an alternative; else handles what remains. Use unless for a simple “not this condition” check. Use case/when when comparing one value against several explicit alternatives.

Write the intended customer message before the code. For example, “show the company only when the contact has one” is a more precise rule than “show a company heading whenever a profile object exists.”

Syntax and supported behavior

Pattern	When to use it
{% if condition %} … {% endif %}	One conditional block.
{% if a %} … {% elsif b %} … {% else %} … {% endif %}	Mutually ordered alternatives; the first matching branch is used.
{% unless value == blank %} … {% endunless %}	Show a block only when a value has meaningful content.
{% case value %}{% when "one" %} … {% else %} … {% endcase %}	Choose among exact values of one variable. Always include a sensible fallback where new values may appear.

Do not assume empty strings or zero are false. A boolean false is different from the text “false.” Use explicit blank checks or comparisons for the actual member type.

Example: show company context without an empty label

{% if sb.profile %}
 <p>Welcome, {{ sb.profile.name | escape }}.</p>
 {% unless sb.profile.company == blank %}
 <p>Company: {{ sb.profile.company | escape }}</p>
 {% endunless %}
{% else %}
 <p>Sign in to use your available customer account features.</p>
{% endif %}

This supports three distinct situations: signed in with a company, signed in without a company value, and signed out. Keep the actual sign-in control from the working page rather than inventing a new authentication flow.

Use case/when for a small presentation choice

{% assign heading_style = "compact" %}
{% case heading_style %}
 {% when "compact" %}<h2>Your requests</h2>
 {% when "full" %}<h1>Your support requests</h1>
 {% else %}<h2>Support requests</h2>
{% endcase %}

Here heading_style is a local presentation variable, not a Supportbench setting. For real record states, prefer supplied readable labels and verified IDs rather than hard-coding assumptions about a customer’s configurable state names.

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
The page reports an unmatched tag	Pair if with endif, unless with endunless and case with endcase. Check nested blocks from the inside outward.
An empty heading appears	Use a blank check on the actual text, not only a truthiness check on its parent object.
No branch covers a new state	Add an honest fallback instead of silently labeling an unknown value as a known outcome.
The conditional changes what a customer can access	It only changes display. Review the real portal permissions separately.

Keep the customization understandable

Test every branch you write. An empty-state sentence should explain the current context and point to an existing useful action, without implying that missing data is a system failure.

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?