> 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/getting-started/dynamic-vs.-flow-components.md). # Dynamic vs. Flow Components Short answer: if you are building on a Lightning page, use Dynamic Components. If you are building inside Flow Builder, use Flow Screen Components. Avonni ships four component lines across three managed packages, so if Experience sites or your own LWC code are also in scope, the [Selection Guide](/choosing-the-right-components/selection-guide.md) is the full picture. This page answers the one question it does not: what happens when a flow screen is asked to do a Lightning page's job. *** ## The line between them | | Dynamic Components | Flow Screen Components | | ------------- | -------------------------------------------- | -------------------------------- | | You build in | Lightning App Builder | Flow Builder | | The user gets | a page that is always there | a step in a process | | Best at | dashboards, record views, data heavy layouts | wizards, intake forms, approvals | | Ships in | Avonni Experience Components | Avonni Flow Screen Components |

In the Dynamic Component Builder: the component is designed once, then placed on any Lightning page.

In Flow Builder: the component is added to a flow screen from the palette, and that screen is one step of the process.

*** ## Flow screens are for guided paths Reach for Flow Screen Components when your users are following a defined path: * Multi-step wizards (case intake, employee onboarding, quote generation) * Approval workflows with user input at specific stages * Guided data entry where the next screen depends on previous answers * Quick actions that collect a few fields and run automation {% hint style="info" %} #### Rule of thumb If your screen has no "Next" button and nobody is moving through steps, you are building a page, not a process. Build it with Dynamic Components. {% endhint %} *** ## The mistake worth avoiding The most frequent one we see is using Flow Screen Components as the layout engine for a full application page: a dashboard, a multi-tab record view, a data heavy layout. Flow screens were not designed for that, and three things follow. **Performance.** Every component on a flow screen loads inside the Salesforce Flow runtime, and the flow's own complexity is part of what the screen has to wait for. The [Performance Guide](/flow/help/performance-guide.md) has the detail and the settings that help. **Reach.** A Dynamic Component is built once and dropped on any page, where it reacts to the rest of that page natively. A flow screen only exists while its flow is running, and its layout belongs to that flow. **Effort.** Page layout work is real work, and it has to be done a second time on the other side the day the page outgrows the flow. *** ## Use both Most orgs install both packages. They coexist with no conflict, and each ships its own Component Builder, so what you learn configuring one carries over to the other. 1. Build the page layout with **Dynamic Components** 2. Trigger the flow from it, with the [Open Flow Dialog](/dynamic-components/component-builder/interactions/open-flow-dialog.md) or Open Flow Panel interaction 3. Build the guided process with **Flow Screen Components** Pages load fast, layouts stay reusable, and guided processes stay guided. --- # 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/dynamic-components/getting-started/dynamic-vs.-flow-components.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.