> For the complete documentation index, see [llms.txt](https://docs.avonnicomponents.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.avonnicomponents.com/dynamic-components/core-concepts/component-visibility.md).

# 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.

{% hint style="info" %}

#### 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**](/dynamic-components/core-concepts/experience-sites-integration.md#visibility-rules-on-experience-cloud) for setup details.
{% endhint %}

***

## 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. |

<figure><img src="/files/IxaPyNhNkXCuTtiXlMH0" alt="" width="323"><figcaption></figcaption></figure>

***

## 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)`).

***

## 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](/dynamic-components/components/button-menu.md).

{% stepper %}
{% step %}

#### **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`).
  {% endstep %}

{% step %}

#### **Add the Calendar**

Drag an Avonni **Calendar** component onto the canvas
{% endstep %}

{% step %}

#### **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`.
  {% endstep %}
  {% endstepper %}

<figure><img src="/files/Hp686IbBlgwb3UbHlvJT" alt=""><figcaption></figcaption></figure>

#### **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.

{% stepper %}
{% step %}
**Add Data Table**

Add your Data Table component (e.g., `MyDataTable`).
{% endstep %}

{% step %}
**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'`.
  {% endstep %}

{% step %}
**Add List Component**

Add your List component (e.g., `MyList`) designed for mobile viewing.
{% endstep %}

{% step %}
**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'`.
  {% endstep %}
  {% endstepper %}

<figure><img src="/files/GTGqYkrDkTsoH93AiYds" alt=""><figcaption></figcaption></figure>

**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.
* **Test Thoroughly:** Test your visibility conditions with different data and user interactions.
* **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`. 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.avonnicomponents.com/dynamic-components/core-concepts/component-visibility.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
