> 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/choosing-the-right-components/selection-guide.md).
# Selection Guide
Five component lines, one question: where are you building today? Follow the path to your answer, then install the package that carries it.
## Start with one question
Avonni gives you **five component lines** across four Salesforce surfaces, delivered in **three managed packages**. Three of the lines are no-code and made for admins. One is a code library for developers. Same component family everywhere: pages, flows, sites, and your own code.
The important thing to know first: **these are not either/or solutions.** Many Avonni users install more than one package, because a real project rarely lives on a single surface. So the question is not "which one do I commit to", it is:
**Where am I building today?**
## The one minute answer
* A **Lightning page** that has to show things, fast: **App Builder Components**.
* A **Lightning page** that needs formulas, components reacting to each other, or branding beyond the Salesforce look: **Dynamic Components**.
* A **screen flow**: **Flow Screen Components**.
* An **Experience Cloud site** for customers or partners: **Experience Sites Components**.
* **Your own Lightning Web Components**: **LWC Components**.
None of those choices closes another one, and a single package covers three of the five lines. The rest of this page explains each answer, and [Installation & Package](https://docs.avonnicomponents.com/choosing-the-right-components/installation-and-package) carries the install links.
## Follow the path
```mermaid
flowchart TD
Q["Where are you building today?"] --> CODE{"Are you writing your own code?"}
CODE -->|"Yes, my own LWC"| LWC["LWC Components"]
CODE -->|"No, I use a Salesforce builder"| B{"Which builder?"}
B -->|"Flow Builder"| FLOW["Flow Screen Components"]
B -->|"Experience Builder"| XP["Experience Sites Components"]
B -->|"Lightning App Builder"| L{"How much logic on the page?"}
L -->|"Show it, fast"| AB["App Builder Components"]
L -->|"Formulas, reactivity, custom branding"| DYN["Dynamic Components"]
```
Every endpoint on that path is a component line, and no path closes another one. You can walk it again next month for a different project.
***
## Where are you building?
### I am in the Lightning App Builder
You are building a page layout: a record page, a Home page, an app page. Two lines cover this surface, and you pick by how much the page has to think.
* [**App Builder Components**](https://docs.avonnicomponents.com/app-builder-components) for quick, standard layouts. Drag a component onto the page, point it at your data, done. Conditional visibility comes from App Builder itself.
* [**Dynamic Components**](https://docs.avonnicomponents.com/dynamic-components) when the page needs formulas, components that react to each other and to record changes, or branding beyond the Salesforce look. This is the closest thing to custom development without code.
**Key strength**: both are always on. They live on the page layout, so nobody has to launch a flow to see the information.
### I am in the Flow Builder
You are building a guided process: step 1, step 2, step 3, to collect data or walk a user through a decision.
* [**Flow Screen Components**](https://docs.avonnicomponents.com/flow) give you more than 70 components made for Screen Flows.
**Key strength**: these components live inside your Flow variables, so they integrate with your business logic, your formulas, and the rest of your automation.
### I am in the Experience Builder
You are building for people outside your org: a customer portal, a partner site, a public page.
* [**Experience Sites Components**](https://docs.avonnicomponents.com/experience-cloud) are built for Experience Cloud, fully branded, and designed for guest access.
**Key strength**: they go well past the Salesforce look, which is usually the whole point of a public-facing site. Dynamic Components work on Experience Cloud too, so a portal can mix both.
### I am writing my own Lightning Web Components
You are a developer, and you want production-ready building blocks instead of starting from scratch.
* [**LWC Components**](https://docs.avonnicomponents.com/lwc-components) give you 55+ components you reference with `avonni-*` tags, exactly like the standard `lightning-*` ones.
**Key strength**: the 12 Data Driven components (Data Table, Kanban, Scheduler, Map, Pivot Table and more) query records themselves, so a full data table is about 30 lines of configuration with no Apex controller behind it.
Pick this line if your team keeps rebuilding tables, boards, calendars and maps; if you want zero Apex for the data display layer, since query mode handles fetching, search, sort, filter and pagination; or if you use AI assistants to write LWC and want them generating against a discoverable catalog instead of scaffolding black boxes.
***
## Which package carries which line
Five lines, three packages. This is the whole mapping:
| Where you build | Component line | Package to install |
| ------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------- |
| Lightning App Builder, quick layouts | [App Builder Components](https://docs.avonnicomponents.com/app-builder-components) | **Avonni Experience Components** |
| Lightning App Builder, logic and reactivity | [Dynamic Components](https://docs.avonnicomponents.com/dynamic-components) | **Avonni Experience Components** |
| Experience Builder | [Experience Sites Components](https://docs.avonnicomponents.com/experience-cloud) | **Avonni Experience Components** |
| Flow Builder | [Flow Screen Components](https://docs.avonnicomponents.com/flow) | **Avonni Flow Screen Components** |
| Your own LWC code | [LWC Components](https://docs.avonnicomponents.com/lwc-components) | **Avonni LWC Components** |
One install of **Avonni Experience Components** therefore covers three of the five lines. See [Installation & Package](https://docs.avonnicomponents.com/choosing-the-right-components/installation-and-package) for the install links and the four steps that follow.
***
## The hybrid strategy
{% hint style="success" %}
#### Most Avonni users do not pick just one
The common pattern: build a reactive dashboard with [Dynamic Components](https://docs.avonnicomponents.com/dynamic-components) directly on a record page, then put a button or an interaction inside it that launches an [Avonni Screen Flow](https://docs.avonnicomponents.com/flow) for the data entry. Developers join the same story through the [LWC Components](https://docs.avonnicomponents.com/lwc-components) package, so their custom code shares the component family your admins already use.
Pages, processes, sites and code, all in one org, all looking like the same product.
{% endhint %}
## Better together
Installing **Avonni Experience Components** is not an upgrade that replaces your Flow components. It is an extension of what you can build.
* **Modern UI**: Dynamic Components make standard Salesforce pages look and behave like custom-coded applications.
* **Triggered logic**: those components can trigger your existing Screen Flows. Clicking "Schedule Meeting" on an Avonni Timeline launches the flow that handles the calendar logic.
* **Custom code**: when a team needs something the builders do not cover, developers build it with the LWC Components package, using the same component family, so the UI stays consistent across the org.
***
## Frequently asked questions
I already use Flow Screen Components. What is my path forward?
Keep using them for everything that happens inside a flow. If you also want components sitting directly on a Lightning record page, outside any flow, add **Avonni Experience Components** alongside. Nothing changes in your existing flows.
I am a developer. Do I need the no-code packages to use LWC Components?
No. LWC Components is standalone: install it and reference any `avonni-*` component in your own code. If admins in your org also use the no-code builders, the packages coexist without conflict, and your custom code shares the same component family as their pages, flows, and sites.
Can one project use several component lines at once?
Yes, and the good ones usually do. A customer portal can run Experience Sites Components for the layout, a Dynamic Component for a reactive dashboard inside it, and a Screen Flow built with Flow Screen Components for the request form. They share styling and behaviour, so it reads as one product to the end user.
Where do the App Builder and Dynamic lines differ, exactly?
Both sit on a Lightning page and both come in the same package, so the choice is about what the page has to do. App Builder Components display data with the Salesforce look and the visibility rules App Builder already gives you. Dynamic Components add formulas, components that react to each other and to record changes, and branding of your own. Start with App Builder Components when the page shows things; move to Dynamic Components when the page has to think.
{% hint style="info" %}
Want the capabilities side by side instead of a decision path? See the [Feature Comparison](https://docs.avonnicomponents.com/choosing-the-right-components/feature-comparison). Ready to install? See [Installation & Package](https://docs.avonnicomponents.com/choosing-the-right-components/installation-and-package).
{% endhint %}
---
# 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, and the optional `goal` query parameter:
```
GET https://docs.avonnicomponents.com/choosing-the-right-components/selection-guide.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.