Ctrlk
YouTube ChannelBook A Demo🪄 Build with AIJoin The Community
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Component Visibility

Overview

Instead of always showing all components, you can define rules that determine when a component is visible. Show a section only when a checkbox is checked, hide a chart on mobile, or display a form only after the user picks an option.

Visibility rules work on Lightning Pages and Experience Cloud sites (both Aura and LWR). The conditions you define in the Component Builder apply at runtime regardless of where the Dynamic Component is deployed.

Info

If you're building on an Experience Cloud site and find that Salesforce Audiences are too broad for your needs, visibility rules give you field-level and interaction-level control over what appears on the page. See Experience Sites Integration for setup details.

How Dynamic Visibility Works

Every Avonni component has a Set Component Visibility panel in the Properties Panel. The When to Display Component dropdown controls when the component is shown:

Option
Behaviour

Always

The component is always visible. This is the default.

All Conditions Are Met

The component is shown only when every condition you define evaluates to true.

Any Condition Is Met

The component is shown when at least one of your conditions evaluates to true.

Custom Logic Is Met

The component is shown based on a custom logical expression you write (e.g. 1 AND (2 OR 3)), referencing your conditions by number.

Setting Up Conditional Visibility

  1. Select the component on the canvas.

  2. Open the Properties Panel (right side) and find the Set Component Visibility section.

  3. Choose a display mode from the When to Display Component dropdown: All Conditions Are Met, Any Condition Is Met, or Custom Logic Is Met.

  4. Add one or more conditions. Each condition compares a value on the left to a value on the right using an operator. The left-hand value can be:

    • Component Attribute: The state or value of another component (e.g., @MyCheckbox.checked).

    • Variable: A Variable resource you created.

    • Formula: A Formula resource, useful for complex expressions.

    • Global Variable: System-provided information such as $Component.FormFactor, which returns 'Desktop', 'Tablet', or 'Phone'.

  5. If using Custom Logic, enter your expression in the logic field using condition numbers (e.g., 1 AND (2 OR 3)).

What a Condition Compares

A condition is evaluated against the value stored on the record, not against the label displayed in the builder or on the page. Most of the time the two are the same text and the condition works as written. When they differ, the condition is false, the component stays hidden, and no error is shown.

Record types are where this comes up most often. The condition editor shows the record type label, for example Distribution Headquarters, while the record stores the API name, for example Distribution_Headquarters. A record type API name cannot contain a space, so a condition written with a multi word label never matches. Single word record types such as Contractor have the same label and API name, which is why conditions on some components work while an apparently identical one does not.

To get the value the condition needs: open Setup, go to Object Manager, select the object, open Record Types, and copy the Record Type Name. Use that text in the condition.

The comparison is exact. A trailing space, a different capitalization, or an abbreviation is enough to make the condition false. The same applies to picklists, where the API value often differs from the label users see.

The field used in a condition also has to be part of the data the component loads, and readable by the user viewing the page. A field the running user cannot read arrives empty, so the condition is false for them while it stays true for an administrator.

The component is hidden and you cannot tell why

Keep the same field in the condition, change the operator to Is Not Null, and reload the page.

If the component appears, the field does reach the component and only the compared value is wrong. Copy the stored value from Setup and try again.

If the component is still hidden, the field never reaches the component. Add it to the data the component loads, then check the object and field permissions of the profile that views the page.

Examples

Conditionally Displaying a Calendar

Let's create an example in which an Avonni Calendar component is visible only when the user selects the "Calendar" option from an Avonni Button Menu.

1

Add a Button Menu

  • Drag an Avonni Button Menu component onto the canvas.

  • In its properties, configure the Items:

    • Add an item with Label: Table, Value: table

    • Add an item with Label: Calendar, Value: calendar

  • Give the Button Menu a descriptive API Name (e.g., ViewModeMenu).

2

Add the Calendar

Drag an Avonni Calendar component onto the canvas

3

Set the Calendar's Visibility

  • Select the Calendar component.

  • In the Properties Panel, open Set Component Visibility.

  • Set When to Display Component to All Conditions Are Met.

  • Add a condition: left side → Component Attribute → ViewModeMenu → value; operator → equals; right side → calendar.

How It Works

The Calendar's Visible property is now directly linked to the value of the ViewModeMenu Button Menu. When the user selects "Calendar" in the Button Menu, the value becomes 'calendar', the condition evaluates to true, and the Calendar component is displayed. If any other option is selected, the condition is false, and the Calendar is not loaded.

Device-Specific Layout

Let's show a detailed Data Table on desktops/tablets, but a simpler List component on phones.

1

Add Data Table

Add your Data Table component (e.g., MyDataTable).

2

Set Data Table Visibility

  • Select MyDataTable.

  • Open Set Component Visibility → set When to Display Component to All Conditions Are Met.

  • Add a condition: Global Variable $Component.FormFactor not equal to 'Phone'.

3

Add List Component

Add your List component (e.g., MyList) designed for mobile viewing.

4

Set List Visibility

  • Select MyList.

  • Open Set Component Visibility → set When to Display Component to All Conditions Are Met.

  • Add a condition: Global Variable $Component.FormFactor equals 'Phone'.

Result: Users on desktops or tablets will see the Data Table, while users viewing on a phone will see the List component, providing an optimized view for each device form factor.

Common Use Cases

  • Conditional Forms: Show/hide form fields based on previous selections.

  • Personalized Dashboards: Display different components based on user role or profile.

  • Progressive Disclosure: Gradually reveal information as the user interacts.

  • Error Messages: Show error messages only when an error occurs.

  • Loading Indicators: Show a loading indicator while data is being fetched, then hide it and show the data component.

  • Creating Responsive Layouts that adapt to Desktop, Tablet, and Phone screens

  • Experience Cloud sites: Control component visibility based on record data or user interactions when Salesforce Audiences don't offer enough granularity. For example, show a Flow only to users whose Account has a specific Type value, or hide a section until the user selects a tab. This works on both Aura and LWR sites.

Tips

  • Start Simple: Begin with simple conditions and gradually increase complexity.

  • Copy Values From Setup: When a condition compares a record type or a picklist, use the stored API value rather than the label.

  • Test Thoroughly: Test your visibility conditions with different data and user interactions.

  • Test As Your Users: An administrator sees fields a standard profile may not, so check the page with a profile your users actually have.

  • Use Formulas Carefully: While powerful, complex formulas can be more complicated to maintain.

  • Use Boolean Variables: Create boolean variables to make it more readable.

In Summary

Use the When to Display Component dropdown, All Conditions Are Met, Any Condition Is Met, or Custom Logic Is Met, to define when a component appears. Conditions can reference component attributes, variables, formulas, or $Component.FormFactor, and they compare against the value stored on the record rather than the label. This works on Lightning Pages and Experience Cloud sites alike. In Experience Cloud, visibility rules provide the fine-grained, condition-based control that Salesforce Audiences doesn't cover.

Last updated

Was this helpful?