Liquid customer profile: personalize the portal with sb.profile

Updated Wednesday, October 28, 2026 · Marc Staine

A small amount of personalization can reassure a B2B customer that they are using the correct account context. sb.profile supplies the current signed-in contact’s display information. Use it for a greeting or account label, while keeping customer permissions and company-wide access governed by the portal’s normal rules.

At a glance

For: portal administrators and designers working with support operations. Applies to: Supportbench Core.

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

What this object gives you · Choose the correct page and customer context · Supported values and how to use them · Example: show a friendly account context · Use company context without promising company-wide access · Make and verify the change · Common problems and recovery · Keep the portal useful over time

What this object gives you

sb.profile is the signed-in customer profile object or null when no such profile is available. It is not the agent currently viewing an administrative preview, and it is not a directory of all contacts at the customer’s company.

The useful profile members here are id, name, company and avatar. Declared compatibility post/comment counters are not populated for this object and should not be used as customer-engagement metrics.

Choose the correct page and customer context

Use a customer portal page that supplies signed-in contact context. A synthetic designer preview can display a sample person; verify the live result with a real authorized test contact. Do not infer account-wide visibility just because the company name is available.

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

Member	Meaning and operational use
id	Current contact/profile identifier. Avoid presenting it as the primary customer-facing label.
name	Current contact’s display name. Escape as text and allow long names to wrap.
company	Associated company display name where available. It can be empty.
avatar	Optional image path. Render an image only when present; otherwise use your normal text or placeholder design.
post_count / comment_count	Compatibility members that are not populated here. Do not label these defaults as verified activity totals.

Example: show a friendly account context

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

Keep the portal’s existing sign-in and account controls. If you add an avatar, choose alternative text appropriate to the design and do not rely on the image alone to identify the user. A missing avatar should not leave a broken-image icon or blank heading.

Use company context without promising company-wide access

A purchasing contact and an equipment technician may belong to the same organization but have different portal permissions. Showing the company name helps them recognize their context; it does not mean both can read every company case.

If a customer says “I can see my company name but not my colleague’s request,” investigate the customer role, case relationships and company visibility configuration. Adding more profile markup cannot change those rules. Keep the wording around request lists specific to the actual scope.

Make and verify the change

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.
Copy the current template into your approved change record before editing. Add the fragment in the correct page context without removing functional controls.
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.
Inspect desktop and narrow-screen layouts. Test long customer names, long titles, missing optional values, readable links and keyboard navigation.
Use Review changes → Publish when the draft is ready. A saved draft does not update the live visitor page.
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.

Preview is only part of the check

Designer examples use synthetic data. They can show layout and syntax problems, but do not prove that a real customer has access to a record. Keep portal access rules and the actual customer test separate from visual preview.

Common problems and recovery

Problem	What to check
The profile is null	Check whether the visitor is signed in as a customer contact and whether this page has profile context.
A company label appears with no value	Guard against blank company text. A contact need not have the company value you expected.
The avatar renders as a broken image	Check for a nonblank avatar path before creating the image element.
The profile name is used as an authorization check	Names are display values. Keep authorization with the portal’s server-side customer rules.
The template renders in preview but the live page has not changed	Confirm that you published the reviewed draft for the correct portal, page and language. Reopen the live page.
A customer sees fewer records than an agent	Check the customer’s portal role, company/contact relationship and the record’s audience. Do not attempt to broaden access by changing a Liquid loop.
A layout change breaks a form or navigation	Compare the changed template with the saved working version. Restore missing form IDs, inputs, URL patterns or callbacks before publishing the corrected draft.

Keep the portal useful over time

Personalization should help the customer orient themselves, not expose unnecessary account details. Recheck the signed-out page and contacts with different company relationships whenever you change the portal header.

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.

Was this article helpful?