Customize customer-portal pages with Supportbench Liquid

Updated Wednesday, October 28, 2026 · Marc Staine

Liquid templates let you shape how customers see knowledge, cases, and account information in a Supportbench portal. A useful B2B portal makes the next action clear while preserving the customer’s permitted view of their organization. Supportbench uses the DotLiquid .NET dialect and its own page-aware data catalog; examples written for another Liquid product may not work here.

At a glance

For: portal administrators, designers, and developers supporting customer self-service. Applies to: Supportbench Core.

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

Start with the page and the reader · Choose objects available on the current page · Use conditions, loops, and empty states · Use Supportbench’s custom tags · Format and localize values · Make the portal useful for B2B customers · Preserve access and safe output · Preview, publish, and verify · Learn the three parts of a Liquid template · Make a small portal improvement and test the reader journey · Troubleshoot template problems

Start with the page and the reader

Open Settings → Customer Portal, select the intended portal, and choose Page templates. The Design preview also offers Edit code in Pages. You need Administer communities or an authorized portal-edit override.

Identify the customer task: finding a solution, reviewing requests, opening a case, or maintaining a profile.
Inspect the existing template before changing it. Preserve its form IDs, inputs, URLs, callbacks, and shared dependencies.
Use the current designer’s object, tag, and filter catalog for the applicable page.
Save template/style changes as drafts, review them, and publish through the portal-design workflow after checking the rendered result.

Liquid changes presentation. It does not create database access, add customer fields, enable a product feature, or grant permissions. The renderer provides a closed set of already-authorized values.

Choose objects available on the current page

Page or purpose	Useful object roots
Knowledge article	sb.article, sb.article_comments
Knowledge topics	sb.container, sb.container_articles, sb.container_articles_latest, sb.container_articles_most_popular, sb.containers, sb.container_list
Search and discovery	sb.search, sb.top_searches, sb.popular_tags, sb.portal_articles_most_popular
Customer requests	sb.cases, sb.cases_company, sb.cases_summary, sb.case
Customer workspace	sb.profile, sb.contacts, sb.contact_details, sb.companies, sb.company_details, sb.projects, sb.project_details, sb.assets, sb.asset
Community discussions	sb.forums, sb.forum, sb.topic
Shared presentation	sb.is_authenticated, sb.require_signin, sb.knowledge_base_enabled, sb.locale, sb.logo, sb.logo_url

These roots are populated only where the route, context, and visitor’s access allow them. An article object is not automatically available on a case-list page. Check the catalog for exact members and types, including whether a value is a collection. A configured customer custom field does not automatically become a new Liquid member.

Use conditions, loops, and empty states

The supported control and variable tags include if, unless, case, for, assign, capture, cycle, comment, raw, break, and continue. Use the standard tags to make the same page useful when a customer is signed out or has no matching records.

{% if sb.is_authenticated %}
 {% for item in sb.cases %}
 <a href="/case/{{ item.id | escape }}">
 {{ item.subject | escape }}
 </a>
 {% else %}
 <p>No requests are available.</p>
 {% endfor %}
{% else %}
 <a href="/signin">Sign in</a>
{% endif %}

This example belongs in a case-list context. The supported rows expose id and subject; the route is /case/ followed by the case ID. Escape text and attribute values at the HTML boundary. Adapt the presentation to the existing template without removing its functional hooks.

Use Supportbench’s custom tags

Tag	Behavior and appropriate use
{% url %}	Encodes the current page URL. It takes no arguments and is not a general route builder.
{% url_encoded %}	Applies the legacy dot/slash/backslash-to-plus transformation before encoding the current page URL.
{% uploader %}	Renders the supported attachment uploader in its existing form context. Preserve the surrounding form and submission behavior.
{% avatar_uploader %}	Renders the profile-avatar uploader in the appropriate profile context.
{% year %}	Renders the current UTC year, useful in a footer.

Do not assume undocumented date tags or Shopify-specific objects exist. Use the catalog in the installed Core build.

Format and localize values

Filter	Purpose
t	Look up a localized key, with an optional fallback.
tf	Replace one named translation placeholder; the default placeholder name is count.
tp	Select the current locale’s plural key and substitute the count.
lnumber	Format a number for the locale.
ldate	Format a locale date; invalid input produces an empty result.
url_encode	URL-encode a text value. In the current Core renderer this resolves to the installed DotLiquid standard filter. Check the result in preview when adapting an older template; do not use it to construct portal routes.
format_bytes	Present a byte count in a readable form.
format_empty	Display an empty string as a dash.

The designer also lists the DotLiquid standard filters supported by the active build. Check their names and argument signatures there. For example, {{ "portal.submit" | t: "Submit" | escape }} localizes a label with a fallback and escapes its text output. URL encoding and HTML escaping serve different purposes. Keep the portal’s existing navigation controls and escape plain text at its HTML output boundary.

Make the portal useful for B2B customers

Example: a customer’s request overview

Use a clear request heading, meaningful subject links, and an understandable empty state. Keep organization context visible where the page supplies it. Preserve the authorized customer/company scope supplied by the server; do not fetch or invent a broader list in a template. Give the customer a clear route to submit a new request or find relevant knowledge.

Use customer-friendly labels consistently across navigation and pages.
Make the next action obvious without crowding the page with every available field.
Keep signed-out and empty states useful, with appropriate navigation.
Check longer translated labels and mobile layouts rather than judging only one desktop example.

Preserve access and safe output

The server decides which cases, articles, companies, and contacts a visitor can access. Hiding a link or section in Liquid is not authorization. Templates cannot call arbitrary database, session, HTTP-context, or application methods.

Escape plain dynamic values such as names, subjects, search text, and URLs. Do not inject untrusted text as HTML. The raw tag displays Liquid source literally; it is not a security boundary. Preserve existing form and authentication branches when changing presentation.

Preview, publish, and verify

Choose the correct page and language in the designer, then inspect the current effective template.
Make a small, purposeful change and save the design draft.
Preview populated, empty, signed-in, and signed-out states where applicable. Preview fixtures are synthetic and do not grant real visitor access.
Check desktop and mobile presentation, long labels, links, search, forms, and uploaders used by the page.
Use Review changes, then the normal Publish action when ready. A saved draft or preview is not a published visitor change.
Open the actual portal in the intended customer scope and verify both the presentation and existing task flow.

Learn the three parts of a Liquid template

A template combines ordinary HTML with instructions that insert available portal data. An object is a value or collection, such as the current article or visible case list. A tag controls behavior such as a condition or loop. A filter formats a value before display. These are presentation tools; they do not grant access to hidden customer records.

For example, a case-list page can loop over the cases supplied for that reader and display each permitted case’s identifier and subject. An article-detail object is only useful when the current page actually has an admitted article. If a value is absent, the template needs an intentional empty state instead of a broken heading or an unexplained blank area.

Begin with one small change to an existing working page. Preserve forms, upload controls and established links unless you understand their role. A beautiful page that prevents a customer from submitting or finding a case is not an improvement.

Make a small portal improvement and test the reader journey

Open Settings → Customer Portal, choose the intended portal, then Page templates. Identify the page the customer actually uses for the task; do not assume an article template controls the case list.
Read the existing markup and identify the wording or block to improve. For a first change, clarify a heading or empty-state explanation while leaving the working form, data bindings and route structure intact.
Choose Save Changes, then open Design to preview representative populated, empty and signed-out sample scenarios. These fixtures are synthetic and do not verify real customer authorization.
Test a normal result and an empty result. For example, a customer with no visible cases should understand how to get help; the page should not imply that there are no cases anywhere in the organization.
Test a longer company/subject value and a narrow screen. Check that links remain readable, tables can scroll when needed and essential instructions are text rather than only an image.
Choose Review changes, then Publish through the supported portal workflow, and revisit the actual portal with the intended customer scope. Confirm its links, forms and access behavior still work.

For a later data-driven change, choose only the objects supported on that page and use the detailed object references. Escape plain values at the HTML boundary and distinguish provided rendered content from arbitrary input. URL encoding and HTML escaping solve different problems; neither should be used to invent a portal route.

Troubleshoot template problems

Problem	Checks and correction
An object is empty	Check the page context, visitor access, and whether the value is a collection or a single object.
A member or filter is unknown	Use the current Supportbench catalog; do not assume a Shopify example is compatible.
A template fails to render	Check matching tags, member spelling, filter arguments, and empty-state handling.
A link is hidden but the record remains accessible	Visibility of a control is not access enforcement. Review the server-side portal/customer rules.
A form stopped working after a visual change	Compare preserved input names, IDs, callbacks, route URLs, and uploader/form context with the prior working template.

Was this article helpful?